[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: egcs produces bloated code by default

On Sun, 25 Oct 1998, Avery Pennarun wrote:

> I compiled my wvdial package.  This is a prerelease of wvdial 1.20, but the
> results should hold for most any C++ program.  If not, then at least any
> version of wvdial.

> First, the raw data.  Here's the difference that optimization settings can
> make.  Yes, all the binaries are stripped.
> -rwxrwxr-x   1 apenwarr apenwarr   102548 Oct 25 17:06 wvdial.mopt*
> -rwxrwxr-x   1 apenwarr apenwarr    66756 Oct 25 17:10 wvdial.neopt*
> -rwxrwxr-x   1 apenwarr apenwarr   109396 Oct 25 17:02 wvdial.noopt*
> -rwxrwxr-x   1 apenwarr apenwarr    63036 Oct 25 17:00 wvdial.opt*
> -rwxrwxr-x   1 apenwarr apenwarr    62332 Oct 25 17:06 wvdialconf.mopt*
> -rwxrwxr-x   1 apenwarr apenwarr    44112 Oct 25 17:10 wvdialconf.neopt*
> -rwxrwxr-x   1 apenwarr apenwarr    68528 Oct 25 17:03 wvdialconf.noopt*
> -rwxrwxr-x   1 apenwarr apenwarr    37396 Oct 25 17:00 wvdialconf.opt*
> The optimizations used for each run:
> .mopt - medium optimization
> 	-O6 -fomit-frame-pointer -fno-implement-inlines
> .neopt - no-exception optimization
> 	-fno-exceptions
> .noopt - no optimization
> 	(nothing)
> .opt - full optimization
> 	-O6 -fomit-frame-pointer -fno-implement-inlines \
> 	-fno-rtti -fno-exceptions
> There's a tremendous size difference between optimized and unoptimized
> versions (opt->noopt is 63k->109k).  This doesn't bother me much, since
> non-optimized code isn't supposed to be all that small or fast.  Fine.

Erm, that's misleading, you are calling '-fno-exceptions' an optimization,
it isn't an optimization it's disabling a feature. The size difference
from .neopt to .opt is 3k which is exactly what you'd expect. The
difference from .mopt -> .noopt is 6k which is pretty expected.

Exception handling adds a good 30% to the object size. hamm egcs added
about 70% (!!!) This only seems to be true for gnu compilers, the others I
have worked with don't have this obscene problem. I have mentioned it to
the egcs people long ago and they sort of admitted it was a problem..

> Is this really acceptable?  When the 2.2 kernel is released, Debian will
> probably switch to using egcs for the C compiler, as well as C++.  That
> means, unless I miss my guess, that almost all of Debian will increase in
> size by 40% unless we add these compile options.  I don't think that should
> be necessary.

No, exception handling is a C++ only feature it will have no effect on C
programs whatsoever [huge egcs bug otherwise]. We have already taken the
size penatly for exception handling when we switched to eg++. 
APT shows similar results, I did these same tests back when I switched to
egcs and they have improved since..

   text    data     bss     dec     hex filename
  29660    4348     116   34124    854c build/bin/apt-cache
  43667    6484     420   50571    c58b build/bin/apt-get
 316702   91800     192  408694   63c76 build/bin/libapt-pkg.so.2.0.0
  28662     748     116   29526    7356 build2/bin/apt-cache
  42813     824     420   44057    ac19 build2/bin/apt-get
 263400    3996      32  267428   414a4 build2/bin/libapt-pkg.so.2.0.0 

[build2 is without exceptions]

Small programs take a small penalty (6k for apt-get) and larger programs
take a large penalty [140k for the library]. If I recall there is sizable
per-function overhead, if you have lots of small functions you will get
just hammered.

If your code doesn't use exceptions then you can safely disable them
otherwise you have to take the penalty.. 

I wish the GNU people could figure out how to fix this, it's a big wart on
the compiler :<


Reply to: