3 ms·

The main issue with unity builds is the simple fact that you get very slow incremental builds. When working on a project you generally want to keep a cache of a

The main issue with unity builds is the simple fact that you get very slow incremental builds. When working on a project you generally want to keep a cache of already-built files to avoid wasting time on a rebuild, while not sacrificing runtime speed in the form of disabling optimizations. With C unity builds don't quickly get very bad, but with C++ it grows fast. This goes hand-in-hand with the fact that for clean builds, parallelizing compilation can improve its speed by a significant amount. And for bigger projects (especially when we're talking C++), unity builds are simply infeasible due to their RAM requirements. Compiling a single file in the firefox code can take up to 3GB at times, and while you may consider it an extreme example, it can be deceptively easy to reach such numbers. All of this is of course not considering the namespace collision issues, where in C++, the "anonymous" namespace is shared across the entire file, and similarly, in C, functions and variables marked as "static" are only visible in the file they're defined in. Both of these are very useful features to reduce verbosity and reduce namespace clutter.

dundarious 5y ago
Implicit in my post was an admonition to avoid the kind of code that causes compilation time explosion. I do acknowledge that nowadays it's very uncommon for people to actually do this -- and I count my past self as one of those people failing to manage compile times properly. Just looking at some cons, with small units you have: - recompilation of the same headers over and over (not really "incremental" then) - must pay increased build system costs for each unit (see https://apenwarr.ca/log/20181113 https://apenwarr.ca/log/20181113) -- something of an open problem - reduced ability to optimize across units (LTO was a bit finicky 10 years ago and it still is today) - reduced developer will to keep compilation times reasonable (workarounds exist like "cloud build systems" such as bazel, which retrieve build artifacts from the cloud, because processing some text files locally is too taxing now) I do agree that there is some project size where a single unity build is too much. But leaving unity/incremental aside, I think there's a strong argument to avoid code that's slow to compile. And if and only if that is agreed upon for a project, then even for very large projects, you can have a unity build for each of the 10 or so modules that make up the system. And if your build is so big, you can use a simple build system like redo for that if you wish, the cost in specification and time is relatively low. However, I think that should be quite rare. We really don't have to pretend we're "optimizing" things by acting like every project we build is the size of firefox or the linux kernel. Let those projects have build systems, and let the remaining 99% of projects just call gcc one or two times. There's very little in the ecosystem of open source software to make doing unity builds very easy, so I'm not chiding anyone for making a tradeoff and using a behemoth like Qt instead of Dear ImGui, because they need assistive tech to work and there's nothing "unity buildable" that supports it.

dundarious 5y ago

Implicit in my post was an admonition to avoid the kind of code that causes compilation time explosion. I do acknowledge that nowadays it's very uncommon for people to actually do this -- and I count my past self as one of those people failing to manage compile times properly. Just looking at some cons, with small units you have: - recompilation of the same headers over and over (not really "incremental" then) - must pay increased build system costs for each unit (see https://apenwarr.ca/log/20181113 https://apenwarr.ca/log/20181113) -- something of an open problem - reduced ability to optimize across units (LTO was a bit finicky 10 years ago and it still is today) - reduced developer will to keep compilation times reasonable (workarounds exist like "cloud build systems" such as bazel, which retrieve build artifacts from the cloud, because processing some text files locally is too taxing now) I do agree that there is some project size where a single unity build is too much. But leaving unity/incremental aside, I think there's a strong argument to avoid code that's slow to compile. And if and only if that is agreed upon for a project, then even for very large projects, you can have a unity build for each of the 10 or so modules that make up the system. And if your build is so big, you can use a simple build system like redo for that if you wish, the cost in specification and time is relatively low. However, I think that should be quite rare. We really don't have to pretend we're "optimizing" things by acting like every project we build is the size of firefox or the linux kernel. Let those projects have build systems, and let the remaining 99% of projects just call gcc one or two times. There's very little in the ecosystem of open source software to make doing unity builds very easy, so I'm not chiding anyone for making a tradeoff and using a behemoth like Qt instead of Dear ImGui, because they need assistive tech to work and there's nothing "unity buildable" that supports it.