Re: gcc compile-time performance

[Jan Hubicka <jh at suse dot cz>]

> Daniel Berlin wrote:
> > 
> > On Fri, 17 May 2002, Dara Hazeghi wrote:
> > 
> > > [...]
> > > 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.
> 
> That's my personal suspicion too, but no, I don't have any real
> evidence.  The lack of hot spots in profiling is a strong hint.
> One oddball idea I've thought about is to functionize all the
> tree and rtl macros, and run a profile on that to see what are
> the most used/abused macros.
> 
> Another idea is to use gcov to identify areas of code that are
> always dead for a particular config, then look at the
> conditionals that guard the dead area.  There are probably
> cases where the conditionals are not ordered for maximal
> efficiency.  (Of course it's possible that a good ordering
> for one config is bad for another.)  The gcov route could also
> identify more opportunities to GC code for obsolete configs.

Unfortunately GCOV also brings relatively balanced results.
The hottest place according to the GCOV are comment skipping loops
in the preprocessor that already has been microoptimized.
> 
> Then there's the extreme approach of having maintainers only
> accept patches that either remove code or make the compiler run
> faster... :-)

I would guess just starting to have daily tests of compile time perofmrance
will solve the large part of problem.  I hope the current spec testers can do
the job.  Let see how noisy the data will be.

Honza
> 
> Stan