Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork3.1k
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
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 checkperformance by ~5.5%.
According tomypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
| items.append(item.accept(self)) | ||
| returnitems | ||
| defexpand_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 toPyList_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, includinglist andtuple.@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 forlist:https://mypyc.readthedocs.io/en/latest/list_operations.html
5f5871d intomasterUh oh!
There was an error while loading.Please reload this page.
| defvisit_instance(self,t:Instance)->Type: | ||
| args=self.expand_types_with_unpack(list(t.args)) | ||
| iflen(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 inexpand_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
tupleandlisttypes. 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%.