This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Apple's implementation of precompiled headers
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Apple's implementation of precompiled headers
- From: Daniel Egger <degger at fhm dot edu>
- Date: 29 Sep 2001 13:36:30 +0200
- Cc: gcc at gcc dot gnu dot org
- References: <3BB4EA68.264BF5AD@apple.com>
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?
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.
--
Servus,
Daniel