FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Micro-optimize ExpandTypeVisitor by JukkaL · Pull Request #19461 · python/mypy · GitHub

Repository navigation

Micro-optimize ExpandTypeVisitor - #19461

Merged
JukkaL merged 1 commit into
masterfrom
opt-3
Jul 17, 2025
Merged

JukkaL merged 1 commit into
masterfrom
opt-3

Conversation

JukkaL commented Jul 16, 2025

Copy link
Copy Markdown
Collaborator

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 requested a review from ilevkivskyi July 16, 2025 13:10

Copy link
Copy Markdown
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Comment thread mypy/expandtype.py
items.append(item.accept(self))
return items

def expand_type_tuple_with_unpack(self, typs: tuple[Type, ...]) -> list[Type]:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 merged commit 5f5871d into master Jul 17, 2025
JukkaL deleted the opt-3 branch July 17, 2025 09:10
Comment thread mypy/expandtype.py
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
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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


Back | FazBrowse Home | New Git URL