This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: The bloat sweepstakes...
- To: Zack Weinberg <zack at codesourcery dot com>
- Subject: Re: The bloat sweepstakes...
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Wed, 10 Oct 2001 16:24:03 +1000
- Cc: gcc at gcc dot gnu dot org
- References: <20011007102535.K9432@codesourcery.com>
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.