Comparing C/C++ unity build with regular build on a large codebase (2024)
PaulHoule
11 points
2 comments
April 01, 2026
Related Discussions
Found 5 related stories in 759.4ms across 14,015 title embeddings via pgvector HNSW
- Show HN: I built a Cargo-like build tool for C/C++ randerson_112 · 137 pts · April 09, 2026 · 52% similar
- Orthodox C++ (2016) signa11 · 93 pts · June 13, 2026 · 50% similar
- Show HN: Claude Code for Visual Studio (native diff with accept/reject) firish · 15 pts · June 15, 2026 · 47% similar
- C extensions, portability, and alternative compilers xngbuilds · 149 pts · May 25, 2026 · 47% similar
- How Claude Code works in large codebases shenli3514 · 78 pts · May 15, 2026 · 47% similar
Discussion Highlights (2 comments)
pstomi
By reading your initial script,I see that there was absolutely no parallelisation in the initial build. Was it a choice because you wanted to compare only single core performances?
jjmarr
If you're doing single-core builds, you will get impressive speedups from unity builds. This is because C++ compilers spends a lot of time redundantly parsing the same headers included in different .cpp files. Normally, you get enough gains from compiling each .cpp file in parallel that it outweighs the parsing, but if you're artificially limited in parallelism then unity builds can pay for themselves very quickly as they did in the article. C++20 modules try to split the difference by parsing each header once into a precompiled module, allowing it to reuse work across different .cpp files. Unfortunately, it means C++ compilation isn't embarrassingly parallel, which is why we have slow buildsystem adoption.