On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote: > Quoting Vladimir Makarov <vmaka...@redhat.com>: >> Reviewers are frequently busy. I bet not a lot of reviewers apply >> patches and play with it. >> >> So it would be nice that people who submits such patches report changes >> in compile time/footprint/build time (at least I am going to ask this >> for parts which I review even if such changes in these parts will be >> not critical for whole compiler as tree or rtl infrastructure changes). >> Otherwise, we are in danger to get slowly degrading compiler. > > I'm not sure that this will be effective against bloat creep. When > considering one small patch that slows down the compiler (and/or slows down > build time) by 0.1%, the difference will be in the noise and impossible to > measure with a manageable sample size. > But if you combine 1100 of such small patches, the compiler will be three > times slower. > > So, unless we can get some coding style/review mechanism in place that > prevents > such bloat creep by examining the source code change and the area where it > is > applied, I think we would need a way to magnify the performance impact > of abstraction penalties. E.g. if the penalty is a vtable lookup, making > it take a hundred times more specifically in the changed places would > magnify the 0.1% overall change to a measurable delta of 10%. Your argument is applicable to any changes in GCC, not just to C to C++ conversions. Do patches that slow down the current C code base by 0.1% get rejected? They do not.
-- VH
