Split unit tests into their own compilation units #257
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of including multiple groups of unit tests via include files into the main unit test harness translation unit, this commits breaks up every group of unit tests into its own translation unit, thus increasing the potential for parallel compilation. Benchmark usign 36 cores indicates an increase in build performance of 2X in debug with clang, 3X in release with gnu, measuring the build of the unittest harness executable only: old: clang/debug:develop$ time ninja unittest [72/72] Linking CXX executable Main/unittest real 0m59.600s user 4m12.360s sys 0m11.720s gnu/release:develop$ time ninja unittest [72/72] Linking CXX executable Main/unittest real 1m30.254s user 4m19.080s sys 0m15.624s new: clang/debug:unittest$ time ninja unittest [115/115] Linking CXX executable Main/unittest real 0m28.627s user 10m16.528s sys 0m26.748s gnu/release:unittest$ time ninja unittest [115/115] Linking CXX executable Main/unittest real 0m27.180s user 9m39.188s sys 0m39.148s
This way when the unit tests register themselves with the global singleton runner, defined in UnitTest.C, using an external reference to the runner in the tut include, at link time, all objects that reference the runner will be visible to the linker in a single step, when linking the unittest executable. Previously the tests, now appearing in multiple compilation units were bundled up into a library which in turn was linked in when creating the executable. While this two-step rpocess worked fine with dynamic linking, static linking, using an intermediate static library, the linker failed to find the same global runner between the executable link and the library.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables more concurrency during compilation and allows rebuilding only the file changed. This leads to more compilation units, but a lot faster compilation of the
unittestexecutable, and thus faster turn-around when writing unit tests.Lots of boring changes, except the one in e84d8ed, which was non-trivial to fix. See also mrzechonek/tut-framework#16.
This change is