This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using C++ in GCC is OK


On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote:
> Quoting Vladimir Makarov <vmakarov@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]