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%.
