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

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Fri, Aug 25, 2000 at 12:28:20PM -0700, Stan Shebs wrote:
> Some very interesting analysis!  Just a couple comments:
> 
> Zack Weinberg wrote:
> > 
> > Third, we could not generate so much data in the first place.  Most of
> > that 45 megs is saved tree representations of inline functions.  Most
> > of those inline functions are never used.  If we could avoid parsing
> > them in the first place, wouldn't that be nice?  Here's where you're
> > all thinking precompiled headers.
> 
> That probably explains the big discrepancy between C and C++ performance.
> Volumewise, only a small percentage of the synthetic example is class
> definitions, but it jumped the compile time by some 50-60%.  Of course,
> this will be more of an issue for systems that use more C++ headers; the
> basic Mac API is 98% C.  On Macs, the primary source of C++ headers is
> Metrowerks' PowerPlant, which is sizeable, but nowhere near the base API.

In fact, I spoke too soon.  Most of the memory consumption is
identifier and declaration nodes, types, and bindings (whatever those
are).  In other words, it wouldn't help memory consumption much to do
lazy parsing of inline functions.  It *would* help parse time, though
- I think.

> Incidentally, I've been on a crash project to add C++ to cpp-precomp
> (as we call it), am learning way more about dark corners of C++ syntax
> than I really wanted to know. :-)

Look over at the conversation I've been having with Mark Mitchell.  He
thinks we can't get away with lazy parsing of anything in C++, and has
some solid arguments for it.

> Also - but keep in mind this is not a promise - I'm getting some
> favorable response to the idea of freeing the sources to
> cpp-precomp.  Although it's not reasonable to try to include any of
> it directly into GCC (it's written in C++, for one thing), it should
> be useful as a source of ideas on how to make precompiled headers
> work.

It won't be me doing it, anymore, but whoever takes over the project
will probably be glad for the ideas.

zw