[ACCEPTED]-#include all .cpp files into a single compilation unit?-build

It's referred to by some (and google-able) as 13 a "Unity Build". It links insanely 12 fast and compiles reasonably quickly as 11 well. It's great for builds you don't need 10 to iterate on, like a release build from 9 a central server, but it isn't necessarily 8 for incremental building.

And it's a PITA 7 to maintain.

EDIT: here's the first google 6 link for more info: http://buffered.io/posts/the-magic-of-unity-builds/

The thing that makes 5 it fast is that the compiler only needs 4 to read in everything once, compile out, then 3 link, rather than doing that for every .cpp 2 file.

Bruce Dawson has a much better write 1 up about this on his blog: http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

Unity builds improved build speeds for three 32 main reasons. The first reason is that all 31 of the shared header files only need to 30 be parsed once. Many C++ projects have a 29 lot of header files that are included by 28 most or all CPP files and the redundant 27 parsing of these is the main cost of compilation, especially 26 if you have many short source files. Precompiled 25 header files can help with this cost, but 24 usually there are a lot of header files 23 which are not precompiled.

The next main 22 reason that unity builds improve build speeds 21 is because the compiler is invoked fewer 20 times. There is some startup cost with invoking 19 the compiler.

Finally, the reduction in redundant 18 header parsing means a reduction in redundant 17 code-gen for inlined functions, so the total 16 size of object files is smaller, which makes 15 linking faster.

Unity builds can also give 14 better code-gen.

Unity builds are NOT faster 13 because of reduced disk I/O. I have profiled 12 many builds with xperf and I know what I'm 11 talking about. If you have sufficient memory 10 then the OS disk cache will avoid the redundant 9 I/O - subsequent reads of a header will 8 come from the OS disk cache. If you don't 7 have enough memory then unity builds could 6 even make build times worse by causing the 5 compiler's memory footprint to exceed available 4 memory and get paged out.

Disk I/O is expensive, which 3 is why all operating systems aggressively 2 cache data in order to avoid redundant disk 1 I/O.

I wonder if that ALL.cpp is attempting to 12 put the entire project within a single compilation 11 unit, to improve the ability for the compiler 10 to optimize the program for size?

Normally 9 some optimizations are only performed within 8 distinct compilation units, such as removal 7 of duplicate code and inlining.

That said, I 6 seem to remember that recent compilers (Microsoft's, Intel's, but 5 I don't think this includes GCC) can do 4 this optimization across multiple compilation 3 units, so I suspect that this 'trick' is 2 unneccessary.

That said, it would be curious 1 to see if there is indeed any difference.

I agree with Bruce; from my experience I 14 had tried implementing the Unity Build for 13 one of my .dll projects which had a ton 12 of header includes and lots of .cpps; to 11 bring down the overall Compilation time 10 on the VS2010(had already exhausted the 9 Incremental Build options) but rather than 8 cutting down the Compilation time, I ran 7 out of memory and the Build not even able 6 to finish the Compilation.

However to add; I 5 did find enabling the Multi-Processor Compilation 4 option in Visual Studio quite helps in cutting 3 down the Compilation time; I am not sure 2 if such an option is available across other 1 platform compilers.

In addition to Bruce Dawson's excellent answer the following 2 link brings more insights onto the pros 1 and cons of unity builds - https://github.com/onqtam/ucm#unity-builds

We have a multi platform project for MacOS 14 and Windows. We have lots of large templates 13 and many headers to include. We halfed build 12 time with Visual Studio 2017 msvc using 11 precompiled headers. For MacOS we tried 10 several days to reduce build time but precompiled 9 headers only reduced build time to 85%. Using 8 a single .cpp-File was the breakthrough. We 7 simply create this ALL.cpp with a script. Our 6 ALL.cpp contains a list of includes of all 5 .cpp-Files of our project. We reduce build 4 time to 30% with XCode 9.0. The only drawback 3 was we had to give names to all private 2 unamed compilation unit namespaces in .cpp-Files. Otherwise 1 the local names will clash.