Re: precompiled headers can cause big slowdowns

[Stan Shebs <shebs at apple dot com>]

Neil Booth wrote:
> 
> Robert Lipe wrote:-
> 
> > It took 97 minutes with the Darwin compiler and cpp-precomp was the
> > consumer of clock cycles.
> 
> That sounds like something silly in cpp-precomp and could probably be
> fixed.  Besides, what these issues really show is that there is a need
> to be able to select whether or not to precompile; not that
> precompiling is necessarily bad.

Exactly, and that's why our cpp-precomp support includes -cpp-precomp
and -no-cpp-precomp flags to explicitly control the choice.  cpp-precomp
works by parsing all of its input and tracking xrefs, so it will always
be slower than a plain preprocessor.  The win comes if the xrefs lead
into a precompiled header, which is an indexed mappable thing and
very efficient to access randomly.  Unfortunately for people porting,
the only standard precompiled headers are for Cocoa or Carbon, plus
there is a "libc.h" that you could add to get all of your standard
system headers in precompiled form; but a "pristine" Unix program won't
include libc.h and won't use any Mac headers, so it doesn't benefit
from the use of cpp-precomp, and may in fact compile more slowly.

In any case, it sounds like Mercury should use -no-cpp-precomp.

Stan