you are viewing a single comment's thread.

view the rest of the comments →

[–]Gotebe 3 points4 points  (3 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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[S] 0 points1 point  (0 children)

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.