public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Speed regression from 3.2 to 3.3
@ 2003-01-21  7:41 Matt Austern
  2003-01-21  7:57 ` Pop Sébastian
  0 siblings, 1 reply; 11+ messages in thread
From: Matt Austern @ 2003-01-21  7:41 UTC (permalink / raw)
  To: gcc

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

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 #2: regression_timing.bz2 --]
[-- Type: application/octet-stream, Size: 1884 bytes --]

[-- Attachment #3: Type: text/plain, Size: 11 bytes --]




  
     

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
@ 2003-01-22 20:48 Richard Guenther
  2003-01-22 20:52 ` Matt Austern
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Guenther @ 2003-01-22 20:48 UTC (permalink / raw)
  To: Joe Buck; +Cc: Matt Austern, gcc

It could be due to the fix Geoff has done to 3.4 to prevent some variable
in ggc-page.c from overflowing causing collecting every alloc that had
been backported only a few days ago. Did you check recent enough 3.3?

Just a thought,

Richard.

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-01-22 21:07 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-21  7:41 Speed regression from 3.2 to 3.3 Matt Austern
2003-01-21  7:57 ` Pop Sébastian
2003-01-21 16:08   ` Jan Hubicka
2003-01-22 10:58     ` Matt Austern
2003-01-22 19:23       ` Andrea 'fwyzard' Bocci
2003-01-22 19:30         ` Matt Austern
2003-01-22 20:45           ` Joe Buck
2003-01-22 20:48             ` Matt Austern
2003-01-22 23:13               ` Mark Mitchell
2003-01-22 20:48 Richard Guenther
2003-01-22 20:52 ` Matt Austern

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).