made TestTokenizerCompileLimits not heavy at all

[firewave]

No description provided.

[firewave]

This limit is obviously not fully helping with the previous example. I will file a ticket about that later.

[firewave]

I somehow didn't bother with moving it back into TestTokenizer. I might do that when I update the costs in a later PR.

[firewave]

Another test also fails:

FAILED performance_test.py::test_crash_array_in_namespace - Failed: Timeout >20.0s

[chrchr-github]

Another test also fails:

FAILED performance_test.py::test_crash_array_in_namespace - Failed: Timeout >20.0s

Seems like issues with MacOS runners are well known, but why the recent slowdown?
actions/runner-images#3885
actions/runner-images#1336
actions/runner-images#8434

[firewave]

The performance of the macOS runners has always been quite inconsistent. But maybe we also introduced some slowdowns. I have not been paying attention to the performance because there are just too many bugs I have been looking into.

[chrchr-github]

Daca execution times haven't changed much:

Time for all packages (not just the ones listed above):
Total time:                                           619799.5   635130.8       1.02

[firewave]

That's a 2% regression on average which means that certain packages might have bigger regressions. Looking at a few packages I see several which have regressed quite but not enough to be listed in our default report which only starts at double times. reducing the factor shows a lot more packages: http://cppcheck1.osuosl.org:8000/time_gt.html?factor=1.1