-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimizing compilation time for the test suite -- an analysis #167
Comments
Hi, thank you, useful analysis! Sidetracked with compilation times, haha, I know that feeling very well :)
|
@mosra: been playing around with some possible improvements here -- https://github.com/vittorioromeo/corrade/tree/wip_type_traits I do get a minor compilation time speedup on my machine, I wonder if it's measurable on yours (or on CI). |
Hey, that's great, thank you! :) I have to think about the compilation time vs maintenance overhead (e.g., "what all do I need to change if a new compiler would implement a builtin of the same name but with different semantics", or the amount of additional test coverage that would be needed for each of these, or how hard will then be for a third party to contribute anything to this codebase given not even the standard type traits would be used anymore), but quite a lot of these seem quite simple and free of compiler magic. Something similar is done in bgfx, and with success, so that's probably a path forward for me as well. Once I fix the bigger fish, like |
I wanted to play around with
corrade
andmagnum
, but got sidetracked and ended up doing a compilation benchmark ofcorrade
(with tests enabled) usingClangBuildAnalyzer
for fun. These are the results:ClangBuildAnalyzer output
Notable things:
There are some very expensive instantiations in the
Tester
class. I tried reducing some of them by controlling instantiation explicitly, but it didn't do much. The wholeCORRADE_COMPARE_AS
mechanism seems to be very heavy on compilation time, I wonder if it can be redesigned to be "nicer".There are some commonly used heavy headers in
corrade
, includingTester.h
,StringView.h
, andPointer.h
. I enabled PCH via CMake after some pain, but surprisingly it didn't make much of a difference. I am not sure why, but probably worth investigating. Precompiling those headers would be a massive time save.There are a bunch of inclusions of
windows.h
without MEAN_AND_LEAN defined. Not sure if intentional.There are some
std::*
utilities and traits that could be replaced with a manual version to avoid instantiation. Even better, variable templates could be used since C++14 instead of classes, which are faster in every major compiler.Unfortunately I don't have anything concrete, but I hope that the analysis helps!
The text was updated successfully, but these errors were encountered: