Re: Apple's implementation of precompiled headers

[Stan Shebs <shebs at apple dot com>]

Daniel Egger wrote:
> 
> On Fre, 2001-09-28 at 23:23, Stan Shebs wrote:
> 
> > Our approach to precompiled headers has been to write GCC's trees
> > and related data into a file, using a format that can be mapped in
> > and randomly accessed. Changes to GCC are not large, mostly to
> > replace the low-level memory allocation machinery, and to add hooks
> > to both "freeze" and "thaw" GCC's internal state.
> 
> So you are serializing GCC's trees after parsing the headers into a
> file. When this file is available at a recompilation you somehow figure
> out whether the #include lines in the code have changed and whether
> the (recursivly) included files themselves are more recent than your
> serialized file. Correct?

Basically yes.  There are many more data structures than trees that
have to be recorded, as it turns out, and we're discovering more as
we go along.

> DICE on the Amiga had a somewhat different approach to reduce the time
> needed to compile files: A given file was checked for it's includes and
> those had were followed and written into a massive header file which
> (if existed) was read into the preprocessor instead of traversing the
> included files themselves. Although the files stayed in ASCII format
> and were rather huge this resulted (when cleverly used) in a drastic
> compile time reduction. Only drawback: There was no decent check for
> changed include files and this probably would have ledd to inferior
> performance since the "not having to traverse dotzends of files on
> a slow filesystem" was the warrant of the speed improvement.

I don't think that's much of an issue for today's systems; a large
flat include file today takes nearly as much time as a complex of
includes.  Easy test is to to take the .i file and run it through
again, compare times.

Stan