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 :<
Jason
Reply to: