This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fw: gcc 3.2 code bloating?


Miguel Ramírez wrote:

> i) far too many templates instantiated due to including the <iostream>

I'm not 100% on this, but I vaguely recollect that largish parts of
iostream and friends had to be reworked for standards compliance:
something along the lines of cout must be a specific instantiation of a
templated class. (Hopefully someone else will fill in the details.)

Assuming you're using the GNU linker it should automatically discard all
instatiated templates that it doesn't use.


> ii) since the binutils are implemented on top of Windoze base services
> there's an overhead of about 20 k

I'm curious what you mean by this. I've seen a lot of people try

    gcc helloworld.c

and MSVC

    cl helloworld.c

and then niavely compare the size of the binaries and say Windows is
bloaded or some such: that isn't a fair comparison. For a suitable linux
or solaris build, for example, GCC defaults to shared C runtime and a
small segment alignment defined by the elf format (16 bytes or
thereabouts?) whereas MSVC staticly links the C runtime and defaults to 4K
segment alignment to match the OS page size. If you instead compile

    cl helloworld.c /MD /link /ALIGN:16

you'll get a similarly sized executable out of MSVC.

Going back to your original question, have you tried size or strip on the
binaries to find out exactly how much is binary or data vs. padding and
debug info? (hence how much actually gets loaded?)

Rup.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]