[cfe-commits] r143100 - in /cfe/trunk: include/clang/Basic/ include/clang/Lex/ include/clang/Sema/ include/clang/Serialization/ lib/Basic/ lib/Lex/ lib/Sema/ lib/Serialization/ test/Modules/

[John McCall]

On Oct 27, 2011, at 8:07 AM, Douglas Gregor wrote:
> On Oct 27, 2011, at 2:52 AM, Douglas Gregor wrote:
>> On Oct 27, 2011, at 2:45 AM, John McCall wrote:
>>> On Oct 27, 2011, at 2:33 AM, Douglas Gregor wrote:
>>>> The results of this optimization are fairly dramatic. On a small
>>>> application that brings in 14 non-trivial modules, this takes modules
>>>> from being > 3x slower than a "perfect" PCH file down to 30% slower
>>>> for a full rebuild. A partial rebuild (where the PCH file or modules
>>>> can be re-used) is down to 7% slower. Making the PCH file just a
>>>> little imperfect (e.g., adding two smallish modules used by a bunch of
>>>> .m files that aren't in the PCH file) tips the scales in favor of the
>>>> modules approach, with 24% faster partial rebuilds.
>>> 
>>> 
>>> You've added an extra generally-not-taken branch to the lexing
>>> of every single identifier-like token;  
>> 
>> Untrue! The out-of-date bit for identifiers feeds into NeedsHandleIdentifier. So, in the no-PCH/no-modules case, we only pay the cost of checking this bit for those identifiers that already have something else interesting going on (e.g., they are poisoned, or need to be macro expanded, or anything else HandleIdentifier does). In the PCH/modules case, we pay the cost of checking that bit once for each known identifier that is uttered after a module import.
>> 
>>> I wouldn't expect that to be
>>> significant, but have you measured and verified that?
>> 
>> 
>> If I actually checked the bit in the hot path of the lexer, it would be a significant regression. But, I'll double-check.
> 
> Verified. There's no measurable performance difference.

Thanks!

John.