This is the mail archive of the gcc@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]

Re: The bloat sweepstakes...


On 07-Oct-2001, Zack Weinberg <zack@codesourcery.com> wrote:
> Largely for amusement, here's some statistics on the sizes of the
> compiler binaries.  All figures are in kilobytes, for the final stage
> of an i386 native bootstrap.  First, the back end:
> 
> text    rodata  data    bss     total   file
> 2360.3  457.2   17.2    494.5   3329.3  libbackend.a

Note that the rodata and bss sizes are both problematic for the Mercury
front-end.  The reason is that the Mercury front-end uses the Boehm
conservative collector, which scans the bss section and
(on most systems) the rodata section.  (There's actually no need for
the conservative collector to scan the rodata section, since that can't
contain pointers to the heap, but unfortunately it's hard to tell where
the rodata section starts and ends.)

This means that if the GCC back-end is linked in with the Mercury
compiler, it will slow down compilation, due to the need for the Boehm GC
to scan those areas.  And this slow-down will occur even if GCC back-end
is not being used, e.g. when compiling via C.

This is a significant disincentive to including the GCC-based
native-code back-end in the standard Mercury distribution.

So it would certainly be nice if those rodata and bss sizes could be
reduced...

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


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