danmar
findtoken.h: make sure code is being matchcompiled
-D __GNUC__ --check-level=exhaustive lib/utils.cpp
Clang 18 851,620,331 -> 809,036,639
GCC 14 880,259,918 -> 841,976,696
This should help with https://trac.cppcheck.net/ticket/12271.
Detecting match calls in headers is tracked in https://trac.cppcheck.net/ticket/11541.
This is obviously extremely horrible and needs to be done differently. Because templates are involved I could not come up with something better for now - but because of the sizable impact I published it anyways.
The example from https://trac.cppcheck.net/ticket/10765#comment:4.
Clang 17 8,156,089,970 -> 7,669,984,764
The example from https://trac.cppcheck.net/ticket/10765#comment:4.
Clang 17 3,753,065,367 -> 3,237,960,965
This makes a lot of difference and we really need to figure out how to get this change in properly.
I do not want the changes to go in this way but I am marking this for review so I hopefully get some more feedback on how to resolve this.
-D __GNUC__ --check-level=exhaustive lib/utils.cpp
Clang 19 699,175,113 -> 652,340,049
GCC 14 744,553,244 -> 702,309,116
The example from https://trac.cppcheck.net/ticket/10765#comment:4.
Clang 19 3,624,176,882 -> 3,063,883,851
GCC 14 3,884,644,414 -> 3,374,187,145
callgrind in the CI
63,702,930,187 -> 63,303,081,301
nice speedups! I am curious.. do you have any theory why there is speedup it just looks like a refactoring to me?
nice speedups! I am curious.. do you have any theory why there is speedup it just looks like a refactoring to me?
The Token::Match() calls were not matchcompiled because they lived in a header. See previous discussion here.
The Token::Match() calls were not matchcompiled because they lived in a header. See previous discussion here.
ah yes! :+1: