-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Regression from 0.750 - Literal types cause significant slowdown #9169
Comments
Are you running on MacOS, if so, check this issue, maybe helpful: #8055 |
No, this is Windows 10, 64-bit.
I do not think this is related to the Another indicator that this is not a startup issue is this. If Finally, there is another clue here - to make my experiments clean, I completely delete the |
I was able to reduce things down to this: The culprit is the large number (270!) of literal values, which seems to be causing the slowdown. |
found the bug
If there's no way to get rid of the nested for loops over I don't feel confident with trying to actually fix this because I don't know what this function is supposed to do, why it has nested loops or why it's called so often. |
Some random thoughts:
IMO the correct way to fix this would be to call the function less often AND make the function run faster when called with many Literals of strings. |
this makes mypy unusable with those aws related stubs, why does this have lower priority than "crashes on invalid syntax" bugs that only a few people have ran into? |
You are reading my mind, @Akuli. As you correctly pointed out, even on your reduced example |
you can use my fix from #9192, it makes mypy usable again |
If this were just locally on my computer, then yes, that would work just fine. The problem comes when other developers need to work on the same source code. Or worse, linters, |
) make_simplified_union no longer runs for 0.5 seconds every time it's called with a Union containing 270 literals of strings. Like I explained in #9169, this only fixes half of the problem and I'm not capable of fixing the other half. This function is still called 1098 times for the "reduced" example code, and IMO it should be called only once.
now it's on mypy master |
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
In PR python#9192 a fast path was created to address the slowness reported in issue python#9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
Closing, since #9192 was merged |
@hauntsaninja Are you sure that this should be closed? #9192 is an ugly workaround that doesn't fix the underlying problem introduced in #8077. |
Sure, I can reopen. #8624 also seems related. |
In PR #9192 a fast path was created to address the slowness reported in issue #9169 wherein large Union or literal types would dramatically slow down typechecking. It is desirable to extend this fast path to cover Enum types, as these can also leverage the O(n) set-based fast path instead of the O(n**2) fallback. This is seen to bring down the typechecking of a single fairly simple chain of `if` statements operating on a large enum (~3k members) from ~40min to 12s in real-world code! Note that the timing is taken from a pure-python run of mypy, as opposed to a compiled version.
Are you reporting a bug, or opening a feature request?
This is a bug. It is a regression from the 0.750 version.
Please insert below the code you are checking with mypy, or a mock-up repro if the source is private. We would appreciate if you try to simplify your case to a minimal repro.
Here is the code that triggers this bug. It is essentially a list of
TypedDict
objects created in some nested fashion. The definitions for these objects are coming from theboto3-stubs
library, which is a typed wrapper around theboto3
library, which is a Python SDK for talking to AWS REST APIs. The same behavior could probably be reproduced with just custom madeTypeDict
objects, but, given, the number of them and the relationship between them, it is easier just to reuse the ones from the library.To install it, you need to have this line in
requirements.txt
(the exact version probably does not matter, but this is what I have):IMPORTANT: After running
pip install
for the above line, one must also run this command to makeboto3-stubs
initialize itself:If doing this from
tox.ini
, you need to have this line there:Here is the offending code:
What is the actual behavior/output?
When running
mypy
for this file, version 0.750 takes about 8-10 seconds to complete without any errors (with a brand new completely empty.mypy_cache
). All versions after that (for the list of versions I tried, see below) essentially hang and never complete. When I was doing this on the actual project code, I hadmypy
running for at least half an hour. When running experiments specifically with the above code, I waited for a couple of minutes for each version before killing it in the Task Manager.What is the behavior/output you expect?
mypy
should not hang on this file.What are the versions of mypy and Python you are using?
mypy
versions tried:Do you see the same issue after installing mypy from Git master?
I only tried the officially published versions listed above.
What are the mypy flags you are using? (For example --strict-optional)
Here is the content of
mypy.ini
that I used:If mypy crashed with a traceback, please paste the full traceback below.
mypy
does not crash, just hangs. It needs to be killed in the Task Manager to stop it. It does not even respond toCtrl
+C
.The text was updated successfully, but these errors were encountered: