GNU bug report logs - #8076
PCH support / howto

Previous Next

Full log

Message #31 received at 8076 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 8076 <at> debbugs.gnu.org
Cc: Dave Hart <davehart <at> gmail.com>, Automake List <automake <at> gnu.org>,
	davehart_gmail_exchange_tee <at> davehart.net, Warren Young <warren <at> etr-usa.com>
Subject: Re: PCH support
Date: Fri, 23 Dec 2011 22:23:03 +0100

Hi Dave.

I'm quoting your mail and CC:ing <8076 <at> debbugs.gnu.org>, 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 <warren <at> etr-usa.com> 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
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.