Recent performance regressions

[JukkaL]

I was looking at self check benchmark results, and I noticed that there were some potential recent performance regressions. Here is a summary:

• Avoid false unreachable and redundant-expr warnings in loops. #18433 (8.7% regression)
• Fix descriptor overload selection #18868 (1.5% regression)

#18845 looks like noise and probably isn't a regression.

It would be good to see if we can reduce the impact of these.

I'm wondering if we could only perform the additional passes introduced in #18433 only when the first pass actually generates an error that we want to fix. If that's the case, we'd discard the errors and apply the new logic.

(Note that the December regression is due to switching from Python 3.8 to 3.13, which is less efficient for our workload.)

cc @tyralla and @ilevkivskyi

[JelleZijlstra]

Python 3.8 to 3.13, which is less efficient for our workload

That's pretty surprising since 3.11 is generally much faster. It might be worth looking into why mypy is slower on a newer version and if that's something we can fix in CPython.

[tyralla]

I'm wondering if we could only perform the additional passes introduced in #18433 only when the first pass actually generates an error that we want to fix. If that's the case, we'd discard the errors and apply the new logic.

8.7 % is much more than I would have expected. Thanks for pointing it out. I should be able to experiment with your idea at the weekend. (I would want to revisit this code anyhow because of #18606.)

[JukkaL]

I think much of the performance regression was from the new reference counting approach introduced in 3.12. #18459 reduced the impact a little.

3.11 is generally faster when running mypy without compilation, but compiled mypy mostly relies on the C API, which hasn't been getting much faster. This is a reasonable tradeoff for Python in general -- most workloads spend a larger fraction of time in the interpreter compared to the C API.

[ilevkivskyi]

OK, I will try to mitigate the performance regression from my PR. I have two ideas:

• Skip overlap check in bind_self() if we know the argument was already handled by check_self_arg(), this should remove some duplicate work.
• Skip both checks completely if the original method has unannotated self. This may require some extra memory for a boolean flag on FuncDef, but it will likely be very minor.

I initially wanted to include those in #18943, but it looks like a separate PR may be OK as well.

[hauntsaninja]

Looks like the recent regressions have been mitigated