> I don't have these around, and I mistakenly updated my tree, so the
> numbers below are, unfortunately, incomparable to the numbers above.
> The disturbing fact is that mainline seems to be significantly slower
> now than it was in my previous tests (from just a few days ago), and
> the slowdown (20%) is much greater than any of the slowdowns we've
> been discussing in this thread. Has anyone else noticed this, or
> perhaps it's something in my environment?

Yes. This first started oscillating about a week or so ago.

http://www.suse.de/~gcctest/c++bench/tramp3d/

Day-to-day resolution is hard to see on these graphs. And, what we
really need is version-to-version resolution anyway...

It's a bummer because up until this point, mainline was making real
progress on compile-time issues. (Of course, anything is going to look
fast compared to 4.2.0.)

FWIW, I liked your earlier idea, that there would be a "speed credit"
whereby people who have done a 4% speed increase could then slow down
the compiler 2% in the future, or something similar. To enforce this,
we'd need a compile-time check as part of "check gcc" then....

I am unfamiliar with this part of gcc to know if there are repeat
offenders, but this might be a way of making all developers more aware
of compile-time costs.

-benjamin

Reply via email to