Compilation time (was Re: GCC 3.3)

[Matt Austern <austern at apple dot com>]

On Tuesday, April 29, 2003, at 09:27 AM, Mark Mitchell wrote:

> On Tue, 2003-04-29 at 07:44, Kaveh R. Ghazi wrote:
> > > In my judgement, the current set of regressions against 3.3 contain 
> > > no
> > > show-stoppers.
> >
> > What about compile-time regressions?
>
> Yes, there are some.  There are some progressions, too.
>
> Some of the ideas I have are too invasive for the release branch; for
> example, I want to go another round on the exceptions/inlining
> interaction, but that's probably not a 3.3 change.
>
> Fundamentally, I don't think there's much more we can do without just
> waiting around hoping someone will fix things.

I agree that compilation time regressions shouldn't be a reason to 
delay 3.3.  That's why I've changed the subject line: I don't think 
this discussion is really relevant to the 3.3 release.  (Although we 
might want to consider applying the patch Gaby posted a couple days 
ago, considering that his work is already done.)

I also agree we should make compilation time a major goal for 3.4.  One 
implication: if this is a major goal, then it's too important to be 
left just to the people who care about compilation time.  One thing 
we've observed at Apple, and I hope people on this list have noticed it 
too, is that performance just leaks away if you're not looking at it.  
Everybody should be thinking about the performance implications of 
their changes, and everyone should be measuring.  Finally, everybody 
should be concerned about small regressions, not just large ones.  A 2% 
performance regression may not seem like much, but if you check in a 
change that causes a 2% regression then you've just put a new work item 
on someone else's queue: find another change to get back that lost 
time.  It doesn't take very many small regressions to make up a 
noticeable degradation.

			--Matt