This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: Noel Yap <yap_noel at yahoo dot com>
- Cc: Stan Shebs <shebs at apple dot com>, Mike Stump <mrs at apple dot com>,gcc at gcc dot gnu dot org
- Date: Sun, 11 Aug 2002 00:15:13 +0100
- Subject: Re: Faster compilation speed
- References: <3D543E54.firstname.lastname@example.org> <email@example.com>
Noel Yap wrote:-
> The study also indicates that having #include's within
> header files is the largest contributor to the problem
> (since nested #include's would increase the number of
> file accesses combinatorially).
See below for why this isn't true for most compilers now.
> As another indication that the conclusion is true,
> Lakos added guards around the #include lines
> themselves and found compile times to dramatically
> decrease. For example:
> #if header_h
> # include <header.h>
This isn't the case with GCC. I hope you're aware of that.
The first time GCC reads <header.h> it remembers if it had
header guards. If it's ever asked to #include it again,
it checks if the guard is defined, and doesn't do anything.
The file's contents are also not cached if it has header
guards, on the assumption that the contents are unlikely to
be of interest in the future.
In other words, this kind of #include protection is ugly and
pointless (and possibly error-prone, though that would tend
to be immediately obvious). Most compilers now implement
this optimization, but 5 or 6 years ago this wasn't the case.
I think GCC was one of the first.