Polymorphism, again

[Legrandin]

Hi
I run into a quite weird problem yesterday.

I've got a complex class (let's call it A) which is the last branch of a
deep tree. It has several virtual methods. In a separate module I define a
hundred of different sibling classes, all inherited from A and each one
having just a constructor and a few one-liners, mainly for re-cast. They
don't override any virtual method.

Well, when I compile the new module I get a *huge* object file
(fair) but even with a static linking the final application is huge as
well.

What's in that object file? I know that polymorphism adds a virtual
table to each class, but here I've got several hundreds Kbytes of
overhead for one hundred classes. Isn't it too much? What does the
compiler do?

BTW, what's a good profiler targeted at minimization of code size?

PS: I use gnu g++ and yes, everything is stripped out and I optimize for
size.

 

[Attila Feher]

Hi
I run into a quite weird problem yesterday.

I've got a complex class (let's call it A) which is the last branch
of a deep tree. It has several virtual methods. In a separate module
I define a hundred of different sibling classes, all inherited from A
and each one having just a constructor and a few one-liners, mainly
for re-cast. They don't override any virtual method.

Well, when I compile the new module I get a *huge* object file
(fair) but even with a static linking the final application is huge as
well.

What's in that object file? I know that polymorphism adds a virtual
table to each class, but here I've got several hundreds Kbytes of
overhead for one hundred classes. Isn't it too much? What does the
compiler do?

BTW, what's a good profiler targeted at minimization of code size?

PS: I use gnu g++ and yes, everything is stripped out and I optimize
for size.

IIRC g++ has a fair warning, that it may not be able to remove duplicate
code, if the linker being used does not support it. So it may be, that for
every object, into which those headers with the million little A-derived
classes get included, will have a million Vtables. My suggestion is to
instruct your linker to make a map file and look at that, and also that
(until you know what makes it big) you consult a g++ newsgroup/list for
further assistance. Then, when you will know what C++ construct makes it
big, it may be possible to find an alternative solution.

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi
I run into a quite weird problem yesterday.

I've got a complex class (let's call it A) which is the last branch of a
deep tree. It has several virtual methods. In a separate module I define a
hundred of different sibling classes, all inherited from A and each one
having just a constructor and a few one-liners, mainly for re-cast. They
don't override any virtual method.

Well, when I compile the new module I get a *huge* object file
(fair) but even with a static linking the final application is huge as
well.

What's in that object file? I know that polymorphism adds a virtual
table to each class, but here I've got several hundreds Kbytes of
overhead for one hundred classes. Isn't it too much? What does the
compiler do?

BTW, what's a good profiler targeted at minimization of code size?

PS: I use gnu g++ and yes, everything is stripped out and I optimize for
size.

A newsgroup appropriate for your OS/compiler is probably more ontopic,
but anyway. You have some large code that perhaps get inlined in each of
these classes ? Get a lot of template instantiation ?
nm -C , objdump,readelf are good tools to examine .o files, atleast if
you're on platforms that uses ELF.(most *nixes)

 

[Legrandin]

IIRC g++ has a fair warning, that it may not be able to remove duplicate
code, if the linker being used does not support it. So it may be, that for
every object, into which those headers with the million little A-derived
classes get included, will have a million Vtables. My suggestion is to
instruct your linker to make a map file and look at that, and also that
(until you know what makes it big) you consult a g++ newsgroup/list for
further assistance. Then, when you will know what C++ construct makes it
big, it may be possible to find an alternative solution.

That's the wisest thing to do and I've already had a look at linker information
but there are so many lines that it's really difficult to spot the problem.
I hoped to find some utility to re-order and translate to an human readble
format but I haven't found anything on the net. I'll try to come out with
some script to do the job.

On my news-server there are no groups dealing with g++, I'm sorry if my post
appeared as an OT. I secretly thought that this problem could be
more theoretical. As a matter of fact, with the Intel compiler I got even
worse results although I didn't play much with it.

To Nils: neither inlines nor templates at all in my case.