#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.)
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.
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.)
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.
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.
Activity
JelleZijlstra commented on Apr 28, 2025
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 commented on Apr 28, 2025
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 commented on Apr 28, 2025
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 commented on Apr 30, 2025
OK, I will try to mitigate the performance regression from my PR. I have two ideas:
I initially wanted to include those in #18943, but it looks like a separate PR may be OK as well.
Speed up bind_self() in trivial cases (#19024)
Avoid false `unreachable` and `redundant-expr` warnings in loops more…
Avoid false `unreachable`, `redundant-expr`, and `redundant-casts` wa…
hauntsaninja commented on Jun 19, 2025
Looks like the recent regressions have been mitigated