* Re: egcs 1.0.2 c++ .o size
@ 1998-03-30 16:18 Mike Stump
1998-04-01 13:41 ` Brian Glendenning
0 siblings, 1 reply; 8+ messages in thread
From: Mike Stump @ 1998-03-30 16:18 UTC (permalink / raw)
To: amylaar, bglenden; +Cc: egcs
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
1998-03-30 16:18 egcs 1.0.2 c++ .o size Mike Stump
@ 1998-04-01 13:41 ` Brian Glendenning
0 siblings, 0 replies; 8+ messages in thread
From: Brian Glendenning @ 1998-04-01 13:41 UTC (permalink / raw)
To: Mike Stump; +Cc: amylaar, egcs
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
1998-03-27 15:18 ` Brian Glendenning
@ 1998-03-31 0:46 ` Jim Wilson
0 siblings, 0 replies; 8+ messages in thread
From: Jim Wilson @ 1998-03-31 0:46 UTC (permalink / raw)
To: Brian Glendenning; +Cc: egcs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
1998-03-27 15:18 ` Joern Rennecke
@ 1998-03-27 15:18 ` Brian Glendenning
1998-03-31 0:46 ` Jim Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Brian Glendenning @ 1998-03-27 15:18 UTC (permalink / raw)
To: Joern Rennecke; +Cc: egcs
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
1998-03-24 16:25 Brian Glendenning
@ 1998-03-27 15:18 ` Joern Rennecke
1998-03-27 15:18 ` Brian Glendenning
1998-03-27 15:18 ` Jeffrey A Law
1 sibling, 1 reply; 8+ messages in thread
From: Joern Rennecke @ 1998-03-27 15:18 UTC (permalink / raw)
To: Brian Glendenning; +Cc: egcs
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
1998-03-24 16:25 Brian Glendenning
1998-03-27 15:18 ` Joern Rennecke
@ 1998-03-27 15:18 ` Jeffrey A Law
1 sibling, 0 replies; 8+ messages in thread
From: Jeffrey A Law @ 1998-03-27 15:18 UTC (permalink / raw)
To: Brian Glendenning; +Cc: egcs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: egcs 1.0.2 c++ .o size
@ 1998-03-26 18:14 Mike Stump
0 siblings, 0 replies; 8+ messages in thread
From: Mike Stump @ 1998-03-26 18:14 UTC (permalink / raw)
To: bglenden, egcs
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* egcs 1.0.2 c++ .o size
@ 1998-03-24 16:25 Brian Glendenning
1998-03-27 15:18 ` Joern Rennecke
1998-03-27 15:18 ` Jeffrey A Law
0 siblings, 2 replies; 8+ messages in thread
From: Brian Glendenning @ 1998-03-24 16:25 UTC (permalink / raw)
To: egcs
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]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1998-04-01 13:41 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-03-30 16:18 egcs 1.0.2 c++ .o size Mike Stump
1998-04-01 13:41 ` Brian Glendenning
-- strict thread matches above, loose matches on Subject: below --
1998-03-26 18:14 Mike Stump
1998-03-24 16:25 Brian Glendenning
1998-03-27 15:18 ` Joern Rennecke
1998-03-27 15:18 ` Brian Glendenning
1998-03-31 0:46 ` Jim Wilson
1998-03-27 15:18 ` Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).