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
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.