4 ms·
> For the 'reference' subsystem of the scheduler, I also improved build speed by consolidating .c files into roughly equal size build units. Instead of 20+ se
by da-x 5y ago
> For the 'reference' subsystem of the scheduler, I also improved build speed by consolidating .c files into roughly equal size build units. Instead of 20+ separate .o's, there's now just 4 .o's being built. Obviously this approach does not scale to the over 30,000 .c files in the kernel, but I wanted to demonstrate it because optimizing at that level brings the next level of build performance, and it might be feasible for a handful of other core kernel
subsystems.
This is important, realizing that compilation units rarely collide on private namespace usage. Called 'compilation unit grouping', or 'CU grouping', I implemented this once at a customer's and reduced build time of a large C++ project by 2x.
- rep_movsd 5y agoI remember doing this - one C file with about 100 lines from #include "file001.c" to #include "file299.c" These were files from a library that used a large number of tiny files, we prefered to embed this in our project rather than link in. Massive build time reduction. There is some technical name for this other than "compilation unit grouping" - I forget what
- tambre 5y agoUnity builds, but also unified and jumbo builds.
- kzrdude 5y agoMerging CU's should preferably be done by the build tool and not have to be written into the .c source files themselves.
- da-x 5y agoExactly that - the implementation of it was done transparently under scons's SConstruct logic.
- jcelerier 5y agoIf you use CMake it's just a matter of setting -DCMAKE_UNITY_BUILD=1