Skip to content

perf: return from is_subtype early #19400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sterliakov
Copy link
Collaborator

Our equality implementation is conservative: if two types compare equal, we know for sure they do indeed refer to the same type, and any type is subtype of itself. This saved 0.9% in my local benchmark run.

@ilevkivskyi
Copy link
Member

I guess this caused performance regression for colours? Or maybe it is just a fluctuation, we will see now. In general I think this may cause performance regression for code with many subtype checks with negative outcome, most notably in overloads checking (which is likely why colours is so slow in the first place).

@sterliakov
Copy link
Collaborator Author

Let's see if the restart helps - I've seen this happening randomly elsewhere.

@sterliakov
Copy link
Collaborator Author

sterliakov commented Jul 8, 2025

Isolated benchmarks also look good: sterliakov/mypy-issues#110

This can have negative effect when almost all subtype checks are expected to fail, but the check should be fast enough to compensate for that. Looking at primer logs, all other projects I looked at (~20 instances from five shards) were checked faster with this patch, so this might be net positive anyway.

Some long-running examples:

/tmp/mypy_primer/mypy_new/venv/bin/mypy on core took 583.57s
/tmp/mypy_primer/mypy_old/venv/bin/mypy on core took 608.09s

/tmp/mypy_primer/mypy_new/venv/bin/mypy on rclip took 30.12s
/tmp/mypy_primer/mypy_old/venv/bin/mypy on rclip took 31.93s

/tmp/mypy_primer/mypy_new/venv/bin/mypy on svcs took 61.66s
/tmp/mypy_primer/mypy_old/venv/bin/mypy on svcs took 63.76s

/tmp/mypy_primer/mypy_new/venv/bin/mypy on arviz took 145.72s
/tmp/mypy_primer/mypy_old/venv/bin/mypy on arviz took 148.53s

This is obviously not the best indicator, but at least something...

colour, however, seems to demonstrate negative impact:

/tmp/mypy_primer/mypy_old/venv/bin/mypy on colour took 3223.60s
/tmp/mypy_primer/mypy_new/venv/bin/mypy on colour took 3298.71s

It's not clear whether any of those are reliable, because the run for #19388 shows significantly lower time with expected positive improvement, but is 3 minutes less for master branch:

/tmp/mypy_primer/mypy_new/venv/bin/mypy on colour took 3013.21s
/tmp/mypy_primer/mypy_old/venv/bin/mypy on colour took 3095.46s

(failing join_artifacts has nothing to do with this PR, it's likely a github outage: https://github.com/python/mypy/actions/runs/16144405699/job/45564336755?pr=19400)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants