Re: egcs 1.0.2 c++ .o size

Re: egcs 1.0.2 c++ .o size

[Mike Stump]

> Date: Thu, 26 Mar 1998 08:59:30 -0700
> From: Brian Glendenning <bglenden@aoc.nrao.edu>

> Is the 50% size penalty going to continue into the future?

Yes, unless someone fixes it.  We all would like to see this number
smaller, but until someone ponies up the work to reduce it...

> We have an exception emulation (setjmp/longjmp, keeping classes
> derived from "Cleanup" in a list) that we'd dearly like to get rid
> of, but 50% is a fairly steep price to pay.

Use -fsjlj-exceptions, and compare against your application without
your extra EH emulation code in the object.  I'm thinking that you
should come pretty close then.

Re: egcs 1.0.2 c++ .o size

[Brian Glendenning]

> Use -fsjlj-exceptions, and compare against your application without

This didn't help (I didn't turn off our emulation, but it is very
cheap).

Here are the figures for an individual .o (all -O2)

gcc 2.7.2                         29k
egcs 1.0.2                        47k
egcs -fno-exceptions -fno-rtti    26k
egcs -fsjlj-exceptions            41k

These size ratio basically follow all the way through to the final
executables. The result of objdump -h is:

Table.egcs.o:     file format elf32-sparc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000316c  00000000  00000000  000000f4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .rodata       0000026f  00000000  00000000  00003260  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  2 .data         00000004  00000000  00000000  000034d0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .dtors        00000004  00000000  00000000  000034d4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .ctors        00000004  00000000  00000000  000034d8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  5 .gcc_except_table 000005a0  00000000  00000000  000034dc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  6 .eh_frame     00000a5c  00000000  00000000  00003a7c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  7 .bss          00000001  00000000  00000000  000044d8  2**0
                  ALLOC
  8 .comment      00000050  00000000  00000000  0000b500  2**0
                  CONTENTS, READONLY

Is this typical, or are we somehow doing something that tickles
particularly bad space behaviour of the exception handling code?

Brian

Re: egcs 1.0.2 c++ .o size

[Mike Stump]

> Date: Tue, 24 Mar 1998 17:25:11 -0700
> From: Brian Glendenning <bglenden@aoc.nrao.edu>
> To: egcs@cygnus.com

> While trying egcs, I noticed that the .o files and resulting executables
> are about 50% larger than their g++ 2.7.2 counterparts when compiled
> optimized (-O2 in both cases) on solaris.

.o files now can have excess code in them that will be thrown away at
link time to deal with template instantiations.  Larger .o files
doesn't necessarily mean larger a.out files.

> Our binaries are already embarrasingly large - I'd hate to have them
> become 50% more so!

> [The debug binaries are about 25% larger]

Try -fno-exceptions and -fno-rtti, if size matters and you don't need
those two features.  I take it you were using size, not ls -l, right?
Also, compare the -O sizes, and see how they differ.

egcs 1.0.2 c++ .o size

[Brian Glendenning]

We have a largish (wc -l *.cc *.h = 780k) set of libraries and
applications (primarily) written in C++. The code is fairly heavily
templated.

While trying egcs, I noticed that the .o files and resulting executables
are about 50% larger than their g++ 2.7.2 counterparts when compiled
optimized (-O2 in both cases) on solaris. Is this common, or is
something bad probably happening (e.g. inlines going static).  If
something bad is probably happening, what are the usual suspects?

Our binaries are already embarrasingly large - I'd hate to have them
become 50% more so!

Thanks! -

Brian

[The debug binaries are about 25% larger]

Re: egcs 1.0.2 c++ .o size

[Joern Rennecke]

> We have a largish (wc -l *.cc *.h = 780k) set of libraries and
> applications (primarily) written in C++. The code is fairly heavily
> templated.
> 
> While trying egcs, I noticed that the .o files and resulting executables
> are about 50% larger than their g++ 2.7.2 counterparts when compiled
> optimized (-O2 in both cases) on solaris. Is this common, or is
> something bad probably happening (e.g. inlines going static).  If
> something bad is probably happening, what are the usual suspects?
> 
> Our binaries are already embarrasingly large - I'd hate to have them
> become 50% more so!

Since 2.7.2 , exception handling has been added.  You can use the
-fno-exceptions option to avoid the overhead of exception handling.

Re: egcs 1.0.2 c++ .o size

[Brian Glendenning]

> > Our binaries are already embarrasingly large - I'd hate to have them
> > become 50% more so!
>
> Since 2.7.2 , exception handling has been added.  You can use the
> -fno-exceptions option to avoid the overhead of exception handling.

OK thanks - indeed that gets our objects down to about the same size (still
about 5% larger).

Is the 50% size penalty going to continue into the future? We have an
exception emulation (setjmp/longjmp, keeping classes derived from "Cleanup"
in a list) that we'd dearly like to get rid of, but 50% is a fairly steep
price to pay.

Brian

Re: egcs 1.0.2 c++ .o size

[Jim Wilson]

	Is the 50% size penalty going to continue into the future? We have an
	exception emulation (setjmp/longjmp, keeping classes derived from "Cleanup"
	in a list) that we'd dearly like to get rid of, but 50% is a fairly steep
	price to pay.

Our first priority was just to get a reasonable non-setjmp mostly machine
independent EH mechanism working, and then worry about optimizing it later.

There have already been a few changes to development versions of GNU as that
help reduce the size of the EH info.  More optimizations are possible, but
I have no idea when people will get around to implementing them.

50% is a lot more executable size increase than I would expect to see on
a sparc target due to EH though.  It is possible that there is some other
problem here.

Jim

Re: egcs 1.0.2 c++ .o size

[Jeffrey A Law]

  In message < 35184EE6.575F538E@aoc.nrao.edu >you write:
  > We have a largish (wc -l *.cc *.h = 780k) set of libraries and
  > applications (primarily) written in C++. The code is fairly heavily
  > templated.
  > 
  > While trying egcs, I noticed that the .o files and resulting executables
  > are about 50% larger than their g++ 2.7.2 counterparts when compiled
  > optimized (-O2 in both cases) on solaris. Is this common, or is
  > something bad probably happening (e.g. inlines going static).  If
  > something bad is probably happening, what are the usual suspects?
  > 
  > Our binaries are already embarrasingly large - I'd hate to have them
  > become 50% more so!
It could be the exception handling overhead.  Use objdump -h to
look at the sizes of various sections.  The name of whatever section
accounts for the growth would probably be enough information for us
to help you with this problem.
jeff