Sent from my iPhone
On Oct 27, 2011, at 3:24 AM, John McCall <[email protected]> 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. > > Ah, okay, so we're checking multiple bits at once and then breaking them out? > That is sensible enough. Yes, exactly. - Doug _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
