> 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