GCC 3.3

[Mark Mitchell]

> 2. Mark _has_ contributed quite a couple of performance improvements,
>    (and so have others).
> 
>    But just because he is release manager and C++ maintainer, nobody can
>    sensibly demand that he fixes all performance issues showing up from
>    C++ code by himself; even more so if many advances of his are more
>    than offset by the creeping slowdown throughout the compiler.
> 
> So, in the end, I suppose that currently both Mark and myself are somehow
> frustrated (at least that's how I understood his reply).

I just don't think that we're going to be able to fix this for 3.3 given
where we presently are.

In practice, we often have a hard time getting people to fix correctness
regressions that they have introduced; compile-time regressions will be
even tougher, and they're tougher to pin on a particular person.  If I
fix a bug, but introduce a 0.25% slowdown, is that a net win or not? 
What if I speed up some piece of generated code by 1%?  When we still
have quadratic algorithms in the compiler, should we worry about my
0.25% slowdown?  Maybe we should invest in fixing those algorithms
instead -- but that requires major work, and we can't expect someone
who's just fixing a bug somewhere to do that.

The good news is that LANL is interested in seeing the C++ compiler run
faster, so Zack and Nathan and I *are* looking at these issues, from a
variety of different angles.

We are lucky in that LANL and Apple (among others, perhaps) are actively
supporting improvements in this area.  

I remain hopeful.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC