Re: [lmi] PCH strategy

[Greg Chicares]

On 2008-08-30 14:16Z, Vadim Zeitlin wrote:

[snip nice summary of pch strategies and issues]

> // This is merely a casual guess, not supported by any measurement of
> // its effect on performance. The optimal set of headers to precompile
> // probably varies by compiler. Including wx headers might impair
> // performance for non-wx targets.
> #   include <wx/wxprec.h>
> 
> but I wonder if you have any hunches about what a better guess could be.

Ten years ago I tuned a pch file carefully for a predecessor to lmi,
with a different compiler. I was repeatedly surprised at how poor
most of my hunches were. That compiler ran an order of magnitude
faster with good pch choices, so tuning was well worthwhile.

Apparently the benefit is more modest with gcc:
  http://people.redhat.com/bkoz/benchmarks/
  http://tromey.com/blog/?p=352
and our code today uses more templates and more standard-library
facilities, so I anticipate that only fresh experimentation will
lead us to the best answer.

> In
> particular, whether there any boost headers which are used often enough to
> be worth including here (most of boost headers take a long time to compile)?

I would consider alternatives to boost where possible. Several boost
libraries have been standardized and are now in libstdc++; using them
instead of the boost originals may reduce bloat. IIRC, boost has a
facility that chooses TR1 and TR2 libraries if the compiler provides
them. As another example, IIRC we recently discussed an alternative to
boost:noncopyable that would use some ideas from Fernando Cacciola;
that would avoid bringing in any headers included by <boost/utility>.

> What about any rarely modified but widely used LMI headers? I can find the
> widely used ones but I don't really know much about the "rarely modified"
> part.

It's really hard to say, and scanning 'ChangeLog' might give the wrong
answer. I have become more zealous about avoiding the need to change
headers. To that end, I have recently made many changes, moving inline
functions and documentation into '.cpp' files. So I've been changing
them often now in order to change them less often later.

>  If not, I'll probably start with the existing pchfile.hpp just because it
> seems like a safe bet -- using it will improve the compilation times a lot,
> already.

I can't devise a better strategy. It will be interesting to see the
effect on speed.