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]
Other format: [Raw text]

Re: GCC 3.2.1 -> GCC 3.3 compile speed regression


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.


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