Uh oh!
There was an error while loading. Please reload this page.
selfcheck.yml: added callgrind step for basic (core) performance tracking - #4171
Conversation
firewave
commented
Jun 5, 2022
Okay - the amount it takes to finish is actually acceptable (a bit over 20 minutes). Using clang should should make things even better. But using the current code base for makes no sense since the code we scan would change with every commit. So it needs to be a fixed corpus - like a release package of our code. |
21e2467 to
f97165bComparefirewave
commented
Jun 7, 2022
With Clang it's less than 20 minutes. We could make it even faster by introduced a hack that we actually only perform the |
408b2ed to
fa78b64Compare* Optimization: Use Token::eIncDecOp instead of expensive Token::Match calls Merged from LCppC. * Small Optimizations: - Moved a std::set that is only need during initialization of SymbolDatabase to function scope - Use std::vector instead of std::list Merged from LCppC. * Optimization: Refactorized various Token::Match calls and surrounding conditions Merged from LCppC. * Refactorization: Cleanup usage of std::multimap Merged from LCppC.
fa78b64 to
c871d31Comparec871d31 to
0fcce2bCompareI think this job also makes sense without have the baseline comparison so we simply collect the performance metric so we can check which commit might have affected the performance in retrospect. The build takes about 14 minutes which is among the slowest in our CI but still a reasonable amount of time. If we are able to optimize a few things that will obviously be faster. Maybe there's also a way to tune this a bit. |
firewave
commented
Sep 23, 2022
The main offender is https://trac.cppcheck.net/ticket/10663 which takes up almost 17% of the whole Ir. |
3a293d1 to
31a5fcfCompare5f73979 to
51788cbComparefirewave
commented
Sep 27, 2022
This is ready for review now. The time it takes (~15 minutes) is reasonable and it will help to track the (core) performance which should only increase. It currently sits at |
51788cb to
101e150Comparecallgrind step for basic (core) performance tracking
Using the
unusedFunctionself-check for profiling gives us a very basic case which involves the core functionality without the valueflow or most of the checks which should be a pretty good canary for speed improvements/regressions. Although the Ir does not translate directly into actual real time speed it would affects other jobs like the sanitized builds and would give an indication if it has any impact at all.