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