Re: PCH, and more generally C++ parser performance

[Mike Stump <mrs at windriver dot com>]

> From: Zack Weinberg <zack@wolery.cumb.org>
> Date: Thu, 24 Aug 2000 18:17:01 -0700

> (1) get_identifier is an easy one.  

> I intend to make get_identifier use cpplib's hash table
> implementation, and share the table itself with cpplib when using an
> integrated preprocessor, which should wipe out this bottleneck.

Sounds good.  Might be interesting to compare with map and hash_map
from the C++ library, and see if those two are in fact worse than
cpplib.  If they aren't, maybe cpplib needs fixing.

> (3) The parser is also bloody slow; we're spending .79 seconds just in
> yyparse.  This is mostly the fault of C++ the language.  Improvements
> in this area will come from giving it less text to grovel through -
> another advantage of the above idea about delaying parsing until
> needed.  (The code that saves inline functions for later uses a
> trivial brace-counting algorithm.)

This describes the way the compiler used to work, then we fixed it.  :-)
The context was templates.  The trick is, once we look it up for
inlining, we want to be able to push into the inline, complete the
compile of it, pop back to the inlining routine and have it inlined.
One can check out older compilers to see the code that did it.

I am told by Mike Ball of Sun that the most compact representation for
saving away inlines (the context was templates as I recall) is in
fact, just source...  so this lends to the idea it might be worth
considering going that direction.  Also, export from template fame
might make use of the same technology.

> It's instructive to note that if you use byacc instead of bison, the
> generated parser is significantly faster - by itself.  The difference
> isn't enough to show up in the total wall clock time.

>   4.96      6.25     0.79        1   790.00 15902.99  yyparse (bison)
>   3.57      7.20     0.57        1   570.00 15916.08  yyparse (byacc)

If one wants to sanity check it, one can gcov it and see where things
are being hit hard, and see if that makes sense.  Sometimes one can
just look at the size of the numbers and say, oh, that's way too high,
trace it down, and find something stupid.


Sounds like some really fine work you've put in, thanks.