-
-
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
mypy appears to become inefficient for nested ifs (13+ nested ifs) #9591
Comments
Hi, can you elaborate the issue a bit? I guess if i understand the problem well, I could try solving it. |
Hello, In case it is not clear (because I don't know how to phrase this differently) -- here are the full-examples with the time consumed by mypy: Example with 13 nested ifs (mypy runtime 0m33.827s)
Example with 14 nested ifs (mypy runtime 1m10.013s)
Example with 15 nested ifs (mypy runtime 2m3.904s)
Example with 16 nested ifs (mypy runtime 4m3.223s)
Example with 17 nested ifs (mypy runtime 8m27.333s)
For me (or the reason why I created the issue) is that it sounds wrong that the mypy runtime doubles, while the complexity of the code only grows linear. In the end this might even expected and considered a "won't fix". |
Thanks for the clarification. Can you assign the issue to me? I am interested in finding solution to it. |
I don't seem to have permission to assign the issue. I'd guess everyone who stumbles over it will see your comment that you intent to work on it :-) |
@PurvaT we generally don't assign issues, but feel free to get started! |
When I run this code on the Windows platform, I got the following error - C:\Users\dhananjay\Desktop>time python3 -m mypy lint_me.py I am unable to run the given code. |
On Windows you could try:
|
I used the above lines to run the code on windows. I got the following output -
I think the running time highly depends on the system as we are measuring a program running time not the asymptotic run rime. Program execution time highly depends on underlying hardware. |
Deeply nested if/else expressions have a worst-case exponential behavior. This will for instance manifest when returning literal values which cause repeated analysis of conditional branches with subtly different type context for each literal. This can be optimized by observing that a simple literal context will yield the same analysis as its fallback type, and likewise, two literals of the same fallback type will yield the same analysis. In those case we can avoid the repeated analysis and prevent the worst-case exponential behavior. Fixes python#9591
This still manifests in master. The root cause is that the typechecker tries to narrow the type of the nested if/else expression and blows up into an exponential number of typechecks with subtly different type contexts. I have a tentative fix for that in #12700 |
Deeply nested if/else expressions have a worst-case exponential behavior. This will for instance manifest when returning literal values which cause repeated analysis of conditional branches with subtly different type context for each literal. This can be optimized by observing that a simple literal context will yield the same analysis as its fallback type, and likewise, two literals of the same fallback type will yield the same analysis. In those case we can avoid the repeated analysis and prevent the worst-case exponential behavior. Fixes python#9591
Deeply nested if/else expressions have a worst-case exponential behavior. This will for instance manifest when returning literal values which cause repeated analysis of conditional branches with subtly different type context for each literal. This can be optimized by observing that a simple literal context will yield the same analysis as its fallback type, and likewise, two literals of the same fallback type will yield the same analysis. In those case we can avoid the repeated analysis and prevent the worst-case exponential behavior. Fixes python#9591
Deeply nested if/else expressions have a worst-case exponential behavior. This will for instance manifest when returning literal values which cause repeated analysis of conditional branches with subtly different type context for each literal. This can be optimized by observing that a simple literal context will yield the same analysis as its fallback type, and likewise, two literals of the same fallback type will yield the same analysis. In those case we can avoid the repeated analysis and prevent the worst-case exponential behavior. Fixes #9591
Deeply nested if/else expressions have a worst-case exponential behavior. This will for instance manifest when returning literal values which cause repeated analysis of conditional branches with subtly different type context for each literal. This can be optimized by observing that a simple literal context will yield the same analysis as its fallback type, and likewise, two literals of the same fallback type will yield the same analysis. In those case we can avoid the repeated analysis and prevent the worst-case exponential behavior. Fixes #9591
Bug Report
mypy appears to become inefficient for nested ifs (see example)
To Reproduce
Consider the following (bad) code example:
Expected Behavior
mypy can complain about very bad code in a reasonable time
Actual Behavior
with each additional
if
the total runtime seems to double:Your Environment
0.790
python -m mypy lint_me.py
)mypy.ini
(and other config files): NonePython 3.8.1
Windows 10, Version 10.0.19041 Build 19041
The text was updated successfully, but these errors were encountered: