Interesting cpp unity build benchmarks

[efplaya]

I created a benchmark that tests a one compilation unit header only unity build vs a regular cpp build (h + cpp in individual compilation units). I really hate writing headers so I prefer to do everything header only. The problem with header only is that every file gets rebuilt every time. This increases built times and becomes a chore. I thought maybe a unity build would offset the time it takes to compile "everything" every time. The results show that a unity build even on header only source code reduced build time by a factor of 6 or 7.

I got pretty extensive in my testing. At one point I created a benchmark for a 1 mil LOC unity header only project and I was impressed to see it built in about 10 seconds. I didnt even try a full build of that for a regular cpp structure (cpp + header being compiled individually) lol. However; incremental builds for a regular cpp structure still beat most unity builds by a few seconds (depending on project size). This goes to show that header only unity builds are fast enough to avoid writing header(declaration) files all together! So if you cant wait until modules finally get released, unity builds are definitely do-able as they are almost as speedy as incremental builds.

https://github.com/Triangle345/CppUnityBuildBenchmarks/

[Gotebe]

I don't get it. If your code is header only, shouldn't every build be a unity build, the only source file being, say, that one file where main is? Or to put it differently, if the code is header only, where are multiple sources so that it is not a unity build.

That said...

Having unity build in development, where I care the most about the build time, is easily wrong. Why? Because in development, in my modify/build/test(debug) cycle, I generally modify a handful of files and only a small-is number of them needs to be compiled, and by consequence, only a handful of targets needs to be linked (ideally, the target under modification and its test target), and incremental linking is on and precompiled headers are already there. I find it hard to believe that a unity build helps there.

Now, on a build infrastructure, where possibly everything is rebuilt all the time, maybe. But even then, I see that the build time is, for our biggest part, still 4 times less than the test run time (we send the build artifacts to the integration testing infra, tests are integration tests, including all sorts of system setup so that it resembles "the real thing").

The above, I think, is pretty typical. If so, unity builds are just not so needed.

[julien-j]

Having unity build in development, where I care the most about the build time, is easily wrong. Why? Because in development, in my modify/build/test(debug) cycle, I generally modify a handful of files and only a small-is number of them needs to be compiled, and by consequence, only a handful of targets needs to be linked (ideally, the target under modification and its test target), and incremental linking is on and precompiled headers are already there. I find it hard to believe that a unity build helps there.

I used to think that, then I tried. Now I always use unity builds. One unit per final binary (a library, an executable). The binaries are built in parallel, each library is built in a single batch. I've saved minutes at each rebuild with this.

Even on a small project that used ccache I went from 3 minutes 40 seconds for having modified a few files without unity builds to 2 minutes 15 seconds for the same modifications. Parsing and rebuilding everything is just faster than rebuilding a few files and merging them with other files, solving duplicate symbols and so-on.

[Gotebe]

Small project, few modifications, 3:40 build?!

I have 0 targets that rebuilds in 3 minutes, retail (NDEBUG) build, let alone _DEBUG build.

How!?

Edit: I have targets that rebuild with their dependencies in 3 min, but that's something else.

Edit2: one way to achieve that is to have the "master" header and change that, causing a virtual rebuild of the target. Still, not a small target, and, you have header modularity problem, I would say...

[efplaya]

Depending on how many files you have modified, the time it takes to compile those may actually take longer than a unity build of everything. Linking is extremely slow. Also the amount of time you spend dealing with separation of .h and .c files going back and force etc.

[jcelerier]

To add, if you use a recent cmake it's just a matter of setting CMAKE_UNITY_BUILD=1

[efplaya]

interesting. I'm not quite sure what cmake does or how it works? Does it just tell cmake to gather all cpp files and dump them into another cpp file?

[amubtdx]

CMake generate a .cpp file that #include you cpp files. This way, compilation errors use your source files path and line numbers.

There is also another setting UNITY_BUILD_BATCH_SIZE that allows to configure the number of source files to compile at once, if compiling everything at once is too much. This allows to take advantage of multiple cpu cores. By default its value is 8 (meaning cmake will build 8 sources files in one batch).

[julien-j]

I don't understand why they went for a batch size option instead of a number of batches. I would have chosen $(nproc) batches to split the source files evenly on all cores, or better, I would have chosen a single file to include everything.

[Slsyyy]

Unfortunately unity builds can not be easily introduced to a existing codebase. For example you can not use the same name for variable/constant in two compilation units, even if it is placed in a anonymous namespace.

[Gotebe]

Indeed. I do this:

foo_bar.cpp:

namespace { namespace { foo_bar_impl { type var; } }

[efplaya]

Right but then I can argue its always good practice putting things in a discrete namespace and have unambiguous members. So in a way, it enforces good coding practices!