-
-
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
Chained calls with medium/large dict/list literals are slow to typecheck #9427
Labels
Comments
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 1, 2022
`fast_dict_type` and `fast_container_type` only allowed Instance but not Tuple of Instances which was mostly an oversight, as opposed to an intentional omission. For python#9427
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 1, 2022
`fast_dict_type` and `fast_container_type` only allowed Instance but not Tuple of Instances which was mostly an oversight, as opposed to an intentional omission. For python#9427
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 1, 2022
When a container (list, set, tuple, or dict) literal expression is used as an argument to an overloaded function it will get repeatedly typechecked. This becomes particularly problematic when the expression is somewhat large, as seen in python#9427 To avoid repeated work, add a new field in the relevant AST nodes to cache the resolved type of the expression. Right now the cache is only used in the fast path, although it could conceivably be leveraged for the slow path as well in a follow-up commit. To further reduce duplicate work, when the fast-path doesn't work, we use the cache to make a note of that, to avoid repeatedly attempting to take the fast path. Fixes python#9427
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 1, 2022
When a container (list, set, tuple, or dict) literal expression is used as an argument to an overloaded function it will get repeatedly typechecked. This becomes particularly problematic when the expression is somewhat large, as seen in python#9427 To avoid repeated work, add a new field in the relevant AST nodes to cache the resolved type of the expression. Right now the cache is only used in the fast path, although it could conceivably be leveraged for the slow path as well in a follow-up commit. To further reduce duplicate work, when the fast-path doesn't work, we use the cache to make a note of that, to avoid repeatedly attempting to take the fast path. Fixes python#9427
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 3, 2022
When a container (list, set, tuple, or dict) literal expression is used as an argument to an overloaded function it will get repeatedly typechecked. This becomes particularly problematic when the expression is somewhat large, as seen in python#9427 To avoid repeated work, add a new field in the relevant AST nodes to cache the resolved type of the expression. Right now the cache is only used in the fast path, although it could conceivably be leveraged for the slow path as well in a follow-up commit. To further reduce duplicate work, when the fast-path doesn't work, we use the cache to make a note of that, to avoid repeatedly attempting to take the fast path. Fixes python#9427
huguesb
pushed a commit
to huguesb/mypy
that referenced
this issue
May 16, 2022
When a container (list, set, tuple, or dict) literal expression is used as an argument to an overloaded function it will get repeatedly typechecked. This becomes particularly problematic when the expression is somewhat large, as seen in python#9427 To avoid repeated work, add a new cache in ExprChecker, mapping the AST node to the resolved type of the expression. Right now the cache is only used in the fast path, although it could conceivably be leveraged for the slow path as well in a follow-up commit. To further reduce duplicate work, when the fast-path doesn't work, we use the cache to make a note of that, to avoid repeatedly attempting to take the fast path. Fixes python#9427
JukkaL
pushed a commit
that referenced
this issue
May 20, 2022
When a container (list, set, tuple, or dict) literal expression is used as an argument to an overloaded function it will get repeatedly typechecked. This becomes particularly problematic when the expression is somewhat large, as seen in #9427 To avoid repeated work, add a new cache in ExprChecker, mapping the AST node to the resolved type of the expression. Right now the cache is only used in the fast path, although it could conceivably be leveraged for the slow path as well in a follow-up commit. To further reduce duplicate work, when the fast-path doesn't work, we use the cache to make a note of that, to avoid repeatedly attempting to take the fast path. Fixes #9427
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Bug Report
Variable assignments with chained calls converting dict/list literals are surprisingly slow to typecheck. Interestingly, breaking down the assignment into multiple steps often yields noticeable performance improvement.
To Reproduce
For instance, consider:
and the same broken down into two steps:
Expected Behavior
I would expect the two samples above to typecheck in roughly equivalent amounts of time.
Actual Behavior
Variant 1 is much slower to typecheck than variant 2: roughly 700ms vs 70ms (not using mypyc-compiled version)
This seems to arise from a combination of repeated computations when typechecking overloaded methods such as
sorted
, typechecking from root to leaf instead of leaf to root, and not caching resolved types for dict/list exprs.Your Environment
The text was updated successfully, but these errors were encountered: