Improve performance of SuppressionsList::isSuppressed by returning as soon as a match is found

[MartinBP]

Improve performance of SuppressionsList::isSuppressed by returning as soon as a match is found.

The same is done in the other overloads of the function. By returning immediately when a match is found, heavily improve the performance of CppCheck::CppCheckLogger reportErr function in cases where a lot of errors are being suppressed.

[firewave]

Thanks for your contribution.

Please provide more details on "heavily improve the performance".

It is possible that this is done intentionally here for the unmatchedSuppression handling. If all tests pass we still need to check that we have proper coverage of such cases (the suppression stuff still lacks coverage and has lots of shortcomings).

This also requires a ticket.

[MartinBP]

Thanks for your contribution.

Please provide more details on "heavily improve the performance".

It is possible that this is done intentionally here for the unmatchedSuppression handling. If all tests pass we still need to check that we have proper coverage of such cases (the suppression stuff still lacks coverage and has lots of shortcomings).

This also requires a ticket.

I ran a test that produced 20755 error messages and the majority of those were suppressed (>99%).
The command used:

cppcheck.exe` --check-level=exhaustive --enable=all --suppress-xml=suppressions-misra.xml --addon=misra.py .\main.c

On my setup (Windows 11 and Intel i7-1260p) the total time went down from 1min 32sec to 45sec.
This is of course controlled by the number of suppressions, how they are written and in what order, so the results may vary from setup to setup.

I have a support ticket open related to slow performance, but it might not be related to the finding I have made here, so creating another ticket would make sense.

It is possible that this is done intentionally here for the unmatchedSuppression handling.

The unmatchedSuppression handling is unaffected by this change.

[MartinBP]

I missed a side effect in the isMatch function.
The function not only checks if it's a match, but it also updates/sets the "checked" and "matched" members of the class.

I will have to investigate what impact this have.

[firewave]

The function not only checks if it's a match, but it also updates/sets the "checked" and "matched" members of the class.

That is probably the "intentional behavior" I meant. The suppression stuff is unfortunately quite complex and there's several things I am still working on. We also need to check if it doesn't cause any regressions with #7079 applied.

[MartinBP]

The function not only checks if it's a match, but it also updates/sets the "checked" and "matched" members of the class.

That is probably the "intentional behavior" I meant. The suppression stuff is unfortunately quite complex and there's several things I am still working on. We also need to check if it doesn't cause any regressions with #7079 applied.

And you were right :)

I have reverted most of the code and instead added a minor optimization that skips calling isMatch when a match has already been found and the suppression being checked has previously been marked as "matched = true".

In my test the time went down from 1min 32sec to 1min 25sec, so no longer a huge save.

[MartinBP]

I did some further debugging and it turned out that the main bottleneck in the suppression check is the file path check (at least in my setup), which made me implement a cache for just that.
See pull request: #8684

The mentioned pull request pretty much makes this one redundant.

[glankk]

Closing in favor of #8684