Skip to content

Recent performance regressions #18991

Closed
Closed

Description

@JukkaL

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

#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

Activity

  1. JelleZijlstra commented on Apr 28, 2025

    @JelleZijlstra
    Member

    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.

  2. tyralla commented on Apr 28, 2025

    @tyralla
    Collaborator

    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.)

  3. JukkaL commented on Apr 28, 2025

    @JukkaL
    CollaboratorAuthor

    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.

  4. ilevkivskyi commented on Apr 30, 2025

    @ilevkivskyi
    Member

    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.

  5. hauntsaninja commented on Jun 19, 2025

    @hauntsaninja
    Collaborator

    Looks like the recent regressions have been mitigated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions