-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Micro-optimize ExpandTypeVisitor #19461
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
Conversation
Specialize a hot for loop for the concrete `tuple` and `list` types. Also add a fast path for empty type arguments. The approach is similar to what I used in #19459. This is a part of a set of micro-optimizations that improve self check performance by ~5.5%.
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
@@ -441,8 +445,19 @@ def expand_types_with_unpack(self, typs: Sequence[Type]) -> list[Type]: | |||
items.append(item.accept(self)) | |||
return items | |||
|
|||
def expand_type_tuple_with_unpack(self, typs: tuple[Type, ...]) -> list[Type]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, it's an interesting optimization I'd never think of. Is this difference significant because of some list operations special-cased by mypyc (something like bypassing __getitem__
and dispatching to PyList_GetItem
directly)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, mypyc uses specialized primitives for the most common built-in types, including list
and tuple
. @jhance has a WIP implementation of a faster sequence iteration implementation, but narrower types are still going to be at least a little more efficient. The specialized operations are listed in the docs -- here are the ones for list
: https://mypyc.readthedocs.io/en/latest/list_operations.html
@@ -209,7 +209,11 @@ def visit_erased_type(self, t: ErasedType) -> Type: | |||
return t | |||
|
|||
def visit_instance(self, t: Instance) -> Type: | |||
args = self.expand_types_with_unpack(list(t.args)) | |||
if len(t.args) == 0: | |||
# TODO: Why do we need to create a copy here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JukkaL It is safer to always create new types in expand_type()
as the caller may sometimes modify the existing type in-place (at least it was the case in the past).
Specialize a hot for loop for the concrete
tuple
andlist
types. Also add a fast path for empty type arguments.The approach is similar to what I used in #19459.
This is a part of a set of micro-optimizations that improve self check performance by ~5.5%.