3 ms·
I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also s
by zarzavat 2y ago
I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.
- kccqzy 2y agoIt's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.
- zarzavat 2y agoDo things that don’t scale :) Obviously it’s not suitable for dev builds, I don’t think anyone uses it for that. For release builds you would want to clear caches anyway.
- kccqzy 2y agoYou don't want to clear caches for release builds. That just makes release builds unnecessarily slow and impedes the flow of Continuous Deployment. You just need to have separate caches for different build flags, including a dedicated cache for release builds.
- account42 2y agoIt does significantly speed up clean builds in many cases, to the point that those clean builds can even be faster than many "incremental" builds in some cases.
- kccqzy 2y agoI do not know of any compiler that can compile different parts of a translation unit in parallel. But plenty of systems (including the venerable `make -j`) can compile separate translation units in parallel because they are independent.
- leni536 2y agoThat's called a "unity build", build systems such as cmake support it. It has its pros and cons.
- account42 2y agoAnd while it helps with compile time (especially with mediocre compilers like MSVC where a large time is spent in the front-end), it doesn't help with stripping unneeded code/data compared to LTO.