This is the mail archive of the
mailing list for the GCC project.
Re: Apple's implementation of precompiled headers
- To: dewar at gnat dot com, shebs at apple dot com
- Subject: Re: Apple's implementation of precompiled headers
- From: dewar at gnat dot com
- Date: Sat, 29 Sep 2001 08:56:47 -0400 (EDT)
- Cc: degger at fhm dot edu, gcc at gcc dot gnu dot org
<<You shouldn't be that amazed, I reported the experimental results
last year. If you want fast compilation of programs with huge
headers (for Macs the round number is 100K lines of header pulled
in per source file), you have to have the set of declarations in
memory and available for random access by name. Parsing, compiling,
reading from disk, all of them take too long.
But they really shouldn't take that long, disks are slow beasts. Yes, it
is certainly understandable that code generation can take a long time, but
it is surprising for front end analysis for a simple language like C to
be this slow. Certainly one should be able to parse C at a million lines
a minute on a modern machine, and there is not much semantic analysis to
do in C.
I am puzzled by the comment on reading from disk, precompiled headers
still have to be read from disk, and the problem is usually that the
precompiled headers are much larger than the sources. So I must be
Obviously keeping stuff in memory from one compilation to another can
be a win for example if this is what you are talking about ...