Skip to content

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

Merged
merged 1 commit into from
Jul 17, 2025
Merged

Micro-optimize ExpandTypeVisitor #19461

merged 1 commit into from
Jul 17, 2025

Conversation

JukkaL
Copy link
Collaborator

@JukkaL JukkaL commented Jul 16, 2025

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%.

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%.
@JukkaL JukkaL requested a review from ilevkivskyi July 16, 2025 13:10
Copy link
Contributor

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]:
Copy link
Collaborator

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)?

Copy link
Collaborator Author

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

@JukkaL JukkaL merged commit 5f5871d into master Jul 17, 2025
20 checks passed
@JukkaL JukkaL deleted the opt-3 branch July 17, 2025 09:10
@@ -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?
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy