21–30 of 64 posts
Compilation units are a relic of a time where computers only had a few KB of memory. At this point computers are fast enough and have enough memory to compile the whole thing in one go faster than whatever gains doing change detection and linking will have.
All of those things combined make C programming more enjoyable.
Earlier quoted context omitted.
Hahaha tell that to my Unreal Engine build times. A brand new AMD Epyc, 64 core machine, will take over an hour to compile. Good times.
I’d really like to see a comparison someday between Epics weird C# based build system and something like CMake+Ninja. I suspect there’s compilation optimizations to be made, but I don’t think it would save more than 30% here and there.
Note that this is not referring to the Game Engine Unity. It's just referring to #including .cpp files.
> This generally leads to faster compilation time in part because it aggregates the cost of parsing the same headers over and over. But this also reduces the opportunity to parallelize compilation across multiple files because they have been concatenated into fewer build units, and each unit now requires more memory to deal with the non-header parts. For some build systems and repositories, this actually increases bu…
Irrelevant. There is always significant overhead in handling multiple translation units, and unity builds simply eliminate that overhead.
> and each unit now requires more memory to deal with the non-header parts.
And that's perfectly ok. You can control how large unity builds are at the component level.
> For some build systems and repositories, this actually increases build time.
You're creating hypothetical problems where there are none.
In the meantime, you're completely missing the main risk of unity builds: increasing the risk of introducing problems associated with internal linkage.
I always use unity builds for all my projects now. That combined with using tcc as compiler (for C code) makes builds really fast. Another nice feature of unity builds is that I don't need to declare functions twice and keep the declarations synced. It's also nice to only have one place to find information about a function; people often put comments in header files that you can miss if you go to the definition. All o…
What exactly leads you to have multiple declarations in sync, and thus creating the to "keep [multiple] declarations synced"?
It is a simple thing to do, and the gains are substantial, faster and simpler, less maintenance, especially across different platforms.
For big projects I simply cut them into several libraries.
I've seen some incredulous reactions, mostly from young coders, and I know that makefiles should be faster, but in practice I never found that to be true.
> This generally leads to faster compilation time in part because it aggregates the cost of parsing the same headers over and over. But this also reduces the opportunity to parallelize compilation across multiple files because they have been concatenated into fewer build units, and each unit now requires more memory to deal with the non-header parts. For some build systems and repositories, this actually increases bu…
Interesting. I've been aware of this technique for years because of the SQLite Amalgamation, but that was always sold as a way to simplify distribution and perhaps improve performance of the binary. I hadn't considered it as a build speed optimization, though that seems somewhat obvious in hindsight.
Some build systems like cmake already support unity builds, as this is a popular strategy to speed up builds.
Nevertheless, if speed is the main concern them it's preferable to just use a build cache like ccache, and modularize a project appropriately.