This is the mail archive of the
mailing list for the GCC project.
gcc 3.3 garbage collector defaults
- From: Andi Kleen <ak at suse dot de>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 27 Jan 2003 16:53:25 +0100
- Subject: gcc 3.3 garbage collector defaults
I experimented a bit with a gcc 3.3 pre release compiler on i686-linux.
One thing I noticed is that it is even slower than gcc 3.2.
This is a big problem for daily development.
Some quick investigation showed that it spends between 16-20% in the
I played a bit with the ggc-min-heapsize and ggc-min-expand parameters,
and it often allowed to bring the gc time to below 10%
Especially the default of ggc-min-heapsize is very low: 30K.
Why this low default?
Why not make it 4-8MB or better scale it with the memory size
of the box?
Another curious thing I noticed is that it often seems to garbage collect
at the end of the translation unit: in one case it did only a few
GCs during the compilation of a lot of functions and then three or four
GCs at the end. That doesn't look very useful. The memory will be freed
with process exit anyways, so these GCs are just wasted time, as long
as the function doesn't need more than a reasonable amount of memory
(in my test cases it was never more than 7MB of GC memory or so)
Perhaps it would be a good idea to not do the gc after each function,
but before each function (= moving it from the end of rest_of_compilation
to the beginning). There are still more ggc_collect calls inbetween,
to handle very big functions, but these could be handled by increasing
ggc-min-expand to 50 or 60%.
Also has anyone investigated why the inbetween individual passes GCs are
needed at all? Perhaps it would be better to use a special
ggc-min-expand value for them and e.g. only do them when the heap expands
by more than 100%. With a big ggc-min-heapsize value this should reduce
GC to one time per function for normal small functions.
Why I would recommend at least is to increase the ridiculously small
default of gcc-min-heapsize