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. ✅ |
| 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.
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.
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
| 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.
@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).
3 participants
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%.