Comparing Python Type Checkers: Speed and Memory
Posted by javabster@reddit | Python | View on Reddit | 32 comments
In our latest type checker comparison blog we cover the speed and memory benchmarks we run regularly across 53 popular open source Python packages. This includes results from a recent run, comparing Pyrefly, Ty, Pyright, and Mypy, although exact results change over time as packages release new versions.
The results from the latest run: Rust-based checkers are roughly an order of magnitude faster, with Pyrefly checking pandas in 1.9 seconds vs. Pyright's 144.
paperlantern-ai@reddit
The speed numbers are wild but I'm curious how much this matters in practice for most people. If you're on a smaller codebase pyright already feels instant, and on larger ones the switching cost is brutal - you'll spend weeks chasing down new errors that your old checker was fine with. Anyone here actually migrated a large project between type checkers? How bad was it?
BeamMeUpBiscotti@reddit
Pyrefly has a few ways to mitigate the switching cost: -
pyrefly initwill read any existing mypy/pyright config and try to generate a Pyrefly config that approximates those settings (including mapping equivalent error codes) -pyrefly suppresswill suppress all errors, which lets you get a clean check right after switching and then look at the errors later. the errors can also be put into a separate baseline file if you don't want suppression comments littering the codepaperlantern-ai@reddit
The conformance test results linked in this thread are worth a look if you haven't clicked through yet. Zuban is way ahead of ty and Pyrefly on spec coverage, which surprised me given how little buzz it gets compared to the other two.
paperlantern-ai@reddit
This is almost certainly not uvicorn itself - a bare uvicorn app should sit around 30-40MB. The fact that you're seeing 512MB+ regardless of which server you try points to something else in your container setup. Since you mentioned using
uv runinside the container, that's likely a big contributor - uv should only be in your build stage, not your runtime. Try a multi-stage Dockerfile: build/install deps with uv in the first stage, then copy just the venv into a cleanpython:3.13-slimfinal stage. You'll probably land around 80-100MB total.poopoutmybuttk@reddit
Zuban seems to be the most mature of the rust type checkers at the moment.
SirPoblington@reddit
Lol what?
npisnotp@reddit
Lol why?
SirPoblington@reddit
Meh I'd never heard of it and it wasn't mentioned in this post. And the github had roughly 600 stars or so. So thought it was sort of randomly thrown in or a self-advertisement. Perhaps I was wrong
npisnotp@reddit
Perphaps; I don't think Github stars are a good measure on maturity or quality.
As you can see in the most recent Python Type System Conformance Test Results from the original comment, Zuban is the LSP that implements most of the Python typing spec, so the affirmation is definitely true.
I'm not saying that is better (its configurability is somewhat lacking compared to Pyright for example) but from all the fast Python type checkers, right now is the most mature by a long shot.
FridayPush@reddit
Ruff would be my thought on most mature Rust type checker. Zuban had days where it sees only a few hundred pypi installs vs 2M+ for ruff. 830+ contributors and personally I've never heard of Zuban before.
Bitruder@reddit
Nor do you know what a type checker is so your knowledge likely isn’t a good signal
FridayPush@reddit
The two other comments 6 hours before yours, and a dozen downvotes, weren't enough to point out my error. Thanks for being part of the community
Stijndcl@reddit
Ruff is a linter. Astral’s type checker (Ty) is by far the least mature one & also has the fewest features covered.
BeamMeUpBiscotti@reddit
Ruff isn't a type checker
AgentCosmic@reddit
Have similar thoughts when trying out the different type checkers. Ty is not even close
skilltheamps@reddit
Yes, especially because it conforms to the specs quite well: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html
For some reason I only heard about it recently, after using mypy and then (based)pyright for years, and giving ty a test run that just confirmed its immaturity.
pacific_plywood@reddit
It clearly is — it helps that it got a multi-year head start
pylessard@reddit
Disappointing article. I don't see memory usage metrics in this article. Also, no feature comparison. I can make a type checker that runs 1000x times faster than any of those, but I won't tell you what it can detect. :)
hopeseeker48@reddit
The latest conformance test results:
https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html
BeamMeUpBiscotti@reddit
The comparison was broken down into several blogs to go more in-depth into each part
here are some others: - https://pyrefly.org/blog/typing-conformance-comparison/ - https://pyrefly.org/blog/container-inference-comparison/
another one that might be useful: - https://positron.posit.co/blog/posts/2026-03-31-python-type-checkers/
tomster10010@reddit
oh zuban is up there
MrSlaw@reddit
Memory usage is recorded in the results json linked at the bottom of the page:
https://github.com/facebook/pyrefly/blob/main/scripts/benchmark/results/2026-04-08-benchmark-macbook-m4.json
pylessard@reddit
Oh, thanks
2ndBrainAI@reddit
These benchmarks are genuinely eye-opening. The 75x speedup of Pyrefly over Pyright on pandas is impressive, but what I'm curious about is correctness parity — does faster necessarily mean fewer false positives/negatives? For teams migrating from Mypy, the incremental type narrowing behavior matters as much as raw speed.
In practice, I've found that editor integration (LSP responsiveness) often matters more day-to-day than CI check time. A 1.9s full-project check is great, but if the inline feedback loop in VS Code is jittery, adoption suffers. Would love to see these benchmarks extended to include incremental re-check time after a single file edit.
hopeseeker48@reddit
The latest conformance test results:
https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html
alphadester@reddit
the Pyrefly vs Pyright gap is what really stands out here. Pyright has been rock solid for years and the ecosystem built around it (pylance, VSCode integration) is massive. Pyrefly being that much faster is impressive but switching costs in large codebases are real. would love to see how they compare on incremental checking specifically
KokoaKuroba@reddit
Hello, newbie here, what is a Python Type Checker? Is it different from type hinting? Is Pyright the default type checker? or is this something you have to deliberately put in your work?
BeamMeUpBiscotti@reddit
It's a tool that checks that the type hints in your Python program are consistent with each other & with the code.
Some type checkers are also language servers, which means they use the type information to power IDE features like hover, go-to-definition, etc.
Pyright is what comes with VS Code right now. Mypy is original type checker, and the most commonly-used by Pypi downloads.
To use a type checker from the command line, you have to install it from pypi or you can run it directly with UV. To use a type checker in VS Code, you can install the extension from the marketplace.
KokoaKuroba@reddit
I see, and when do these type checker "check" the packages? Is it during code execution?
-LeopardShark-@reddit
You have to run it yourself, typically on the command line, within your editor or in continuous integration checks.
fnord123@reddit
Most (all?) of these type checkers also serve as LSPs so they do symbol resolution. Using one of the faster type checkers as an lsp means you can jump around your project using symbol lookup much faster and reindexing when you change branches is faster.
BeamMeUpBiscotti@reddit
Before execution. You can choose when to run it. Commonly, it can be used in 3 places:
1) your editor runs it automatically as you edit the code/save files 2) you manually run it before running your tests (this can save you a lot of time if your tests are very slow) 3) you run it in Github Actions (or similar) to make sure that pull requests from other people do not break things