This is the mail archive of the 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 compile-time performance

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
> > > 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 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

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