Re: gcc compile-time performance

[Daniel Berlin <dberlin at dberlin dot org>]

On Fri, 17 May 2002, Dara Hazeghi wrote:

> On Thursday 16 May 2002 12:09 pm, Neil Booth wrote:
> > Andi Kleen wrote:-
> >
> > > I guess the only way to avoid such things in the future would be to track
> > > the compiler performance of mainline (similar to how the performance of
> > > the resulting code is tracked at http://www.suse.de/~aj/SPEC/index.html).
> > > Then it would be obvious which changes caused bad performance
> > > regressions.
> >
> > I suspect that might be a good idea.
> 
> Hmm...
> 
> I think the next problem would be to determine what is and isn't a relevant 
> test. Obviously gcc 2.7.2.3 works for testing the C front-end (heck, the SPEC 
> folks agree too...). Would it make sense to come up with a bunch of 
> "representative" applications for the various front-ends? Alternatively, 
> would it make more sense to track the compile time of the SPEC builds 
> (shouldn't be too difficult).
> 
> Now the other problem is how to distinguish noise from real compile-time 
> performance regressions, as much of the differences in performance up 'til 
> now seem to have most likely been a cumulative effect of hundreds of patches 
> (I have no data to back this up, just a personal opinion).

I think we actually *do* have data to back this up somewhere.
I also remember Stan Shebs mentioning it at some point (Stan, maybe i'm 
misremembering, so if i just attributed something to you that you never 
said, ....).

Much like a software project gets a year late one day at a time, gcc has 
gotten 5 minutes slower at compiling one second at a time.

 > 
> Just thinking out loud...
> 
> Thanks,
> 
> Dara
>