[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Reducing build times
- From: Mart Raudsepp <leio@xxxxxxxxxxxx>
- Date: Wed, 07 Jun 2006 07:47:24 +0300
- Subject: Re: [XaraXtreme-dev] Reducing build times
On Tue, 2006-06-06 at 13:11 +0100, Alex Bligh wrote:
> Would anyone object to me programatically removing any explicit
> includes of any .h files which are already included in camtypes.h?
> I am pretty sure gcc does not have MSVC's "don't even bother
> opening this header because you've seen it all before" optimization,
> and gcc 3.4 (build server) definitely doesn't.
gcc 3.4 does have it. But it doesn't work in combination with PCH,
If a header is included with gcc, it'll store the fact that it has been
already included in memory and not bother again for that compilation
However this assumes
a) The header has include guards beginning and ending the file, not
counting comments and white-space (the #ifndef for the header guard must
be the first code/preprocessor thing, and the #endif the last thing)
b) The header doesn't come from a PCH (*.h.gch)
This means that GCC does have "don't even bother opening (nor stat'ing)
this header because you've seen it all before" if there certainly is no
need for this, but it currently seems to fail to know the header
guard/files that are all in some precompiled header together. And that's
really sad :(
I tested this myself long ago, and I think I tested with gcc3.3, 3.4 and
4.0 all with the same results (non-PCH header optimization is good, PCH
Just clarifying, the proposed action seems good in my eyes, given the
circumstances and use-case here:
If camtypes.h is the pre-compiled header (as it is), then removing
headers that are contained in there does make sense to speed things up
with reducing the number of file opens.
Easy to test too with strace.
Personally I'm not a big fan of a big header file that includes close to
the whole world (in case of no PCH), but fortunately precompiled header
support is becoming the norm.
> There's no reason to have these files included in cpp files,
> and they are normally also wrong in .h files (exception: .h
> files which are actually in the pch which may need them).
> This should speed up build times, and discourage others from
> using pointless includes.
> Question: Should I
> a) Remove references only to .h files /explicitly/ included
> in camtypes.h (i.e. there is a "#include" there)
> b) Remove references to .h files explicitly or implicitly
> included in camtypes.h (e.g. ones included from another
> .h file).
> c) As (a) but after ensuring there are no implicitly
> included .h files (i.e. make them all explicit).
> The latter is safe, but gives a greater likelihood of
> compile errors if an .h file in the pch is changed not
> to include a given file.
> My preference is (c).