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. |
ethanhs
added
bug
ethanhs
changed the title
|
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.
|
I faced the same issue recently. We have huge Literal with list of project features. Currently it have 269 items. I track problem to this line of code: It generates And then it again loop it 2 times so it is 5 300 000 000 iterations for 1 (!) union check in code. And we have few hundreds of them... Is there anything we can do with this P.S. Python3.10, mypy0.910 update: I think it is fixed in master branch (and future 920 release) |
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
TypedDictobjects created in some nested fashion. The definitions for these objects are coming from theboto3-stubslibrary, which is a typed wrapper around theboto3library, which is a Python SDK for talking to AWS REST APIs. The same behavior could probably be reproduced with just custom madeTypeDictobjects, 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 installfor the above line, one must also run this command to makeboto3-stubsinitialize 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
mypyfor 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 hadmypyrunning 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?
mypyshould not hang on this file.What are the versions of mypy and Python you are using?
mypyversions 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.inithat I used:If mypy crashed with a traceback, please paste the full traceback below.
mypydoes 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: