This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.2.1 -> GCC 3.3 compile speed regression
- From: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: gcc at gcc dot gnu dot org, Geoffrey Keating <geoffk at apple dot com>
- Date: Fri, 31 Jan 2003 16:15:49 +1100
- Subject: Re: GCC 3.2.1 -> GCC 3.3 compile speed regression
- References: <FFC36F04-34C5-11D7-9ECE-000393673036@apple.com>
On 30-Jan-2003, Ziemowit Laski <zlaski@apple.com> wrote:
> 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.
How do the number of allocations compare?
It sounds like 3.3 is allocating a lot more soon-to-be-garbage data than 3.2.1.
It could be useful to produce an allocation profile, showing which
functions were responsible for increased numbers of allocations.
That is, instrument ggc_alloc() so that it records each allocation
in a hash table mapping from allocation site to allocation counts
For identifying allocation sites, you can use __FUNCTION__ (you'd need
to rename the definition of ggc_alloc() and instead define ggc_alloc()
to a macro which passes __FUNCTION__ to the renamed version).
Do this for both 3.2.1 and 3.3, and it should be easy to see which
function(s) are doing a lot more allocations.
--
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.