Speed regression from 3.2 to 3.3

[Matt Austern <austern at apple dot com>]

I wanted to get some more information on the scope of the regression;
we've got a lot of fragmentary information flying around.  I'm trying to
measure one specific case, which I hope is representative, of the
regression in C++ compilation speed from 3.2 to 3.3.  For "3.2" I chose
gcc_3_2_1_release.  For "3.3" I chose  the top of gcc-3_3_branch as
of this morning.  I did my measurements on a 1.5GHz P4 system, running
Linux 2.4.x.  I made sure to run each measurement 5 times to verify that
I had reproducible results.

My measurement: compiling a single file from one of the QT example
programs.  You can reproduce my results by unpacking qt-x11-free-3.1.1,
going into examples/xml/tagreader-with-features, and compiling the file
structureparser.cpp.  I compiled it with all the same flags as it's 
given in
the ordinary QT makefile, except that I compiled it at -O0.

OK, so the broad outline of what I've found out so far:

1. The regression is huge, a change from 3.3s real time to 4.9s.
    That's 48%.  The regression is almost entirely in user time,
    as opposed to system time.
2. The back end is irrelevant, since I used -O0.  As far as this
     regression goes, none of the fancy optimization algorithms matter.
     Using -ftime-report: the only phases that consistently account  for
     more than 1% of the time are garbage collection, preprocessing,
     lexical analysis, and parsing.  Parsing dominates, with roughly
     50% of total time.
 3. All of the regression is accounted for by regressions in the gc
     and parser phases.  Average gc time went up from 0.6s to 1.4s,
     and average parser time went up from 2.3s to 2.9s.

I find the gc regression to be particularly interesting.  First, note 
that
this can't be accounted for by the bug that Geoff fixed.  Even if it
applied to this test case, which it doesn't, Geoff fixed it in the 3.3
release branch a week ago.   So what can the gc regression mean?
Logically, I can only think of two possibilities: either the gc 
algorithm
suddenly got worse, or else the gc is now working on twice as much
memory as it used to.  Both possibilities are a bit hard to believe, but
the second strikes me as far more plausible than the first.

Advice on tracking this down more precisely?

			--Matt

P.S.  For those who want to see my raw data, I'm including it as
an attachment.

Attachment: regression_timing.bz2
Description: Binary data