Re: PCH support

[Dave Hart]

On Fri, Dec 23, 2011 at 20:51, Warren Young <address@hidden> wrote:
> The only important thing to know is that it's a way to make the compiler
> dump its parse tree to disk during compilation so that it can simply reload
> that state from disk instead of rebuilding it from scratch for each module
> it builds.
>
> You might think of PCH as a similar optimization to that of a bytecode
> compiler for a dynamic language: it doesn't get you native code, like you
> can get with a traditional static language, but you still get a speed
> benefit by avoiding reparsing.
>
> PCH is most valuable with headers like STL which are commonly used across
> the program and are expensive to parse and reparse and re-reparse.

True, but most C/C++ #includes orders of magnitudes more lines than
they contain themselves, so assuming the source code is rearranged to
have a "precomp.h" containing the bulk of #includes, the compile will
be notably faster.

> I think the idea is that if autoconf detects that PCH is available and
> automake generates the correct compiler commands to use it, it will be there
> "for free" to any user of the autotools.  Builds just get magically faster.

Given the source changes needed to leverage PCH, I suspect it'll take
a bit of maintainer involvement to enable useful PCH support in each
package.

> There's a monkey wrench, in that PCH doesn't work well if you don't organize
> your header files to take advantage of it.  Say you have a program with 20
> modules, and none of them have any commonality in their #include lines.  PCH
> might make such a build *slower*.  PCH gets its biggest benefit when you can
> make the includes as similar as possible across modules, at least up to a
> point.
>
> Visual C++ avoids this trap by generating a header file for the project
> which you're supposed to #include in every module, and in which goes
> #includes for the most commonly used things.  (stdio.h, windows.h...) The
> project is configured to only generate PCH output for that one header, so
> there is none of the cache thrashing that happens in my 20-modules example.
>
> I'm sure you care nothing for Visual C++, but most of the people begging for
> PCH support are probably coming from this world.

Another monkey wrench is gcc and Visual C++ have different models for
how PCH is implemented.  Support in Automake would ideally target both
by finding a compatible subset.  I'm sure there are existing
open-source models that demonstrate how to use both gcc and VC
precompiled headers.  As I recall, gcc support is a bit more generic
but involves a separate PCH invocation to "compile" the headers, while
VC++ requires precomp.h be the first item included in each
participating file but doesn't require a separate compiler invocation
-- the first one that can use the precomp.pch generates it.

The compile-time savings can be relatively huge.  Support in Automake
would be lovely and I'd be happy to help test any patches.

Cheers,
Dave Hart