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.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
