0

To speed up the compilation of a large source file does it make more sense to prune back the sheer number of headers used in a translation unit, or does the cost of compiling code far outweigh the time it takes to process-out an include-guarded header?

If the latter is true an engineering effort would be better spent creating more, lightweight headers instead of less.

So how long does it take for a modern compiler to handle a header that is effectively include-guarded out? At what point would the inclusion of such headers become a hit on compilation performance?

(related to this question)

Community
  • 1
  • 1
fbrereto
  • 35,429
  • 19
  • 126
  • 178

3 Answers3

1

I read an FAQ about this the other day... first off, write the correct headers, i.e. include all headers that you use and don't depend on undocumented dependencies (which may and will change).

Second, compilers usually recognize include guards these days, so they're fairly efficient. However, you still need to open a lot of files, which may become a burden in large projects. One suggestion was to do this:

Header file:

// file.hpp

#ifndef H_FILE
#define H_FILE

/* ... */

#endif

Now to use the header in your source file, add an extra #ifndef:

// source.cpp

#ifndef H_FILE
#  include <file.hpp>
#endif

It'll be noisier in the source file, and you require predictable include guard names, but you could potentially avoid a lot of include-directives like that.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • you have to *open* the headers at least once, so if the compiler quickly detects include guards what do you gain? – Karoly Horvath Jul 13 '11 at 23:31
  • @yi_H: The second code block goes inside the source file (I edited that in). The point is that if `file.hpp` has already been included, you never need to _open_ `file.hpp` to find its include guard. – Kerrek SB Jul 13 '11 at 23:33
  • I don't know how compilers work but if I wrote one I would store in a flag whether the header is guarded, if so and the constant still defined then there is no need to open and include it again. do compilers use such kind of mechanism? if so, the whole extra proposed guards are pointless. – Karoly Horvath Jul 13 '11 at 23:36
  • It's quite possible that they do. In which case you'd already be doing as well as you could, unless you're willing to restructure the headers and create forward-declaration-only headers, I guess. – Kerrek SB Jul 13 '11 at 23:38
  • Thanks for the comment. Any suggestions on how to go about timing the compiler's ability to deal with include-guarded headers v. "pre-guarding" them as you describe above? – fbrereto Jul 13 '11 at 23:43
  • `#pragma once` is a good way to encourage a compiler to flag the file to not be reprocessed. – Ben Voigt Jul 14 '11 at 00:21
  • @Ben Voigt gcc at least already notices the include gaurds and will do the equivalent of `#pragma once` all by itself to such files. – Spudd86 Feb 13 '12 at 20:41
1

Assuming C/C++, simple recompilation of header files scales non-linearly for a large system (hundreds of files), so if compilation performance is an issue, it is very likely down to that. At least unless you are trying to compile a million line source file on a 1980s era PC...

Pre-compiled headers are available for most compilers, but generally take specific configuration and management to work on non system-headers, which not every project does.

See for example:

http://www.cygnus-software.com/papers/precompiledheaders.html

'Build time on my project is now 15% of what it was before!'

Beyond that, you need to look at the techniques in:

http://www.amazon.com/exec/obidos/ASIN/0201633620/qid%3D990165010/002-0139320-7720029

Or split the system into multiple parts with clean, non-header-based interfaces between them, say .NET components.

soru
  • 5,464
  • 26
  • 30
  • I discovered PCHs recently (while fighting with Boost) and I love them, but I got lots of negative reactions from people when asked about the topic... – Kerrek SB Jul 13 '11 at 23:52
0

The answer:

It can be very expensive!

I found an article where someone had done some testing of the very issue addressed here, and am astonished to find you can increase your compilation time under MSVC by at least an order of magnitude if you write your include guards properly:

http://www.bobarcher.org/software/include/index.html

The most astonishing line from the results is that a test file compiled under MSVC 2008 goes from 5.48s to 0.13s given the right include guard methodology.

fbrereto
  • 35,429
  • 19
  • 126
  • 178