Re: GCC 3.2.1 -> GCC 3.3 compile speed regression

[Zack Weinberg <zack at codesourcery dot com>]

Ziemowit Laski <zlaski@apple.com> writes:

[lots of good juicy data]

> Immediately, a culprit comes to mind:  The 3.3 compiler performs
> almost TWICE AS MANY COLLECTIONS as the 3.2.1 compiler, with a roughly
> comparable # of gcc_collect() calls.  This can't be cheap.
>
> What we see from the GC numbers is that the 3.3 collections are able
> to reclaim a greater percentage of allocated memory at each turn.
> This could be a combination of two factors:
>    - Data in the 3.3 compiler have better temporal locality (!!)
>    - The 3.2.1 collector was buggy/incomplete and could not reliably
> reclaim some stuff.
>
> Anyway, this better reclamation done by the 3.3 ggc also explains why
> the collections occur more frequently there.

[...]

> This leads me to the following half-baked hypothesis: Some kinds of
> data/information that used to persist across the entire compilation
> are now created and destroyed repeatedly in some local temporal scope,
> like the compilation of a single function.  This hypothesis would
> explain not only the increased number of gc passes, but also the
> overall performance degradation we see (even with gc turned off).

A suggestion:  Make ggc_collect a macro like this:

#define ggc_collect() ggc_collect_real(__FUNCTION__)

and then have ggc_collect_real print out the caller but only when it
decides to do a collection.  That'll tell us if, say, all the
additional collections in 3.3 are happening in the same place.

zw