Re: PCH support

[Warren Young]

On 12/23/2011 9:46 AM, Stefano Lattarini wrote:
> I know basically nothing about PCH,

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.

> and it seems to me that it is not
> a feature many users would require or employ.

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.

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.

Bottom line, such a feature, if ever added, should probably be optional.