Hi Dave. I'm quoting your mail and CC:ing <[email protected]>, so that your reply will be registered into the proper entry of the Automake bug tracker.
Anybody, please send further replies and follow-ups to that address if possible, so that this discussion will be properly registered. Thanks, Stefano On 12/23/2011 10:11 PM, Dave Hart wrote: > 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 >
