On Fri, Dec 23, 2011 at 20:51, Warren Young <[email protected]> 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
