0

Consider (using Visual C++ as an example):

cl /EHsc a.cpp b.cpp c.cpp

versus

cat a.cpp b.cpp c.cpp > unity.cpp
cl /EHsc unity.cpp

Why is the first variant slower given a modern compiler? I've seen people say that unity builds avoid headers being parsed multiple times. But then why doesn't a modern compiler cache its header parse results and reuse them between compilation units? Well, they already do. That's what precompiled headers are. But then why not do it automatically for everything all the time? You might say that the order of includes, undefs, and other weird shit can matter, but that's the pathological/exceptional case. You could still detect a well behaved header file and cache it, could you not?

1
  • 2
    add the /showIncludes flag and compare how many times a file gets loaded. Even the most basic standard header will have a massive include list. May 29, 2017 at 9:05

1 Answer 1

4

Most C and C++ header files (notably system headers, or those of large C++ libraries like Qt) have #include guards or the non-standard #pragma once. Practically speaking, standard C++ headers like <set> or <map> are often expanded to at least ten thousand lines each.

So when some translation unit (like your unity.cpp) is including some given one header file foo.h several times, it gets included only once (the first occurrence of its #include).

Hence, the preprocessed form of unity.cpp is shorter (in preprocessed tokens) than the sum of the preprocessed form of each of a.cpp, b.cpp, c.cpp.

And you could check that by getting their preprocessed form. With GCC you would use (perhaps adding other preprocessor options like -I... to add an include directory, -D... to define a preprocessor symbol, -H to get the included files' path, ...)

g++ -C -E a.cpp > a.ii
g++ -C -E b.cpp > b.ii
g++ -C -E c.cpp > c.ii
g++ -C -E unity.cpp > unity.ii

and you could compare the cumulated word count obtained by wc a.ii b.ii c.ii with the one of wc unity.ii

(I leave you to adapt these Linux commands to your cl compiler & Windows)

However, having several translation units enable parallel builds (in several processes running simultaneously), e.g. with make -j.

(Hence, in practical terms, you may want some trade-off; I've got the habit of having *.cc files of a few thousand lines)

You might say that the order of includes, undefs, and other weird shit can matter, but that's the pathological/exceptional case.

I am not sure it is pathological. On Linux, I would presume it could be quite common. See feature_test_macros(7)

You could still detect a well behaved header file and cache it

In practice, that does not work well. Within GCC, some clever people worked on preparsed headers without success. Future C++ standards might define modules (See also Clang documentation on them)

NB: I am answering with a Linux & GCC -centric view, but you could adapt my answer to your Visual C++ & Windows (which I don't know) because it is much more a language (and practical) issue than an operating system & compiler one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.