Oliver Stöneberg

> What is the use case for this? Getting rid of "hidden" thresholds and bailouts (and too many branches). There is also something going on with `TestTokenizerCompileLimits` I still want...

The current limit is way too high and still might have significant impact on performance. So some people might need to lower that. Making it configurable will make it easier...

I did not fix all of them because they might interfere with readability and such. I might back out some changes present here.

I would have preferred to use the existing PR. This way we lost all the discussion/context of these changes which is really bad (I never understand why people delete PRs...

> Please add a test in `test/cli/performance_test.py`. The test already exists and it is the one failing with this change applied. So somehow this actually makes things worse.

There is a less intrusive way to address this by exiting early - see #7822.

Seems a bit convoluted but as I do not understand this kind of processing well I leave it up to others to comment. Still some notes.

> May need more work after #7800 and #7803, so I'm leaving it as a draft for now. For some additional extended manual testing you could use the invocation added...

Not in the scope of this PR but I wonder if it would make sense to add a debug message if a function is being omitted from analysis.

``` [238/238][20.0s] clang-tidy-19 -p=/home/runner/work/cppcheck/cppcheck/cmake.output -quiet /home/runner/work/cppcheck/cppcheck/gui/xmlreport.cpp /home/runner/work/cppcheck/cppcheck/lib/utils.h:57:5: error: an exception may be thrown in function '~OnExit' which should not throw exceptions [bugprone-exception-escape,-warnings-as-errors] 57 | ~OnExit() { | ^ ``` I...