Merging LOAD_METHOD
and LOAD_ATTR
for better specialization
#400
Replies: 4 comments 12 replies
-
If I understand correctly, what you are suggesting is similar to what we do with When you say "the unbound method optimisation" do you mean avoiding the creation of bound methods, or something else? If you want to try this, then I'd suggest keeping |
Beta Was this translation helpful? Give feedback.
-
I like this idea. To summarize my thoughts:
The semantics of |
Beta Was this translation helpful? Give feedback.
-
It might be worth taking a look at #396 before doing this. |
Beta Was this translation helpful? Give feedback.
-
I opened python/cpython#93430 for this.
Agreed. We can reduce the cache size after merging too. Unless the bigger cache actually causes an immediate perf regression. |
Beta Was this translation helpful? Give feedback.
-
Currently, a good portion of
LOAD_METHOD
failures are that the method is an instance attribute.I've always wondered if we could overwrite
LOAD_METHOD
withLOAD_ATTR
, then letLOAD_ATTR
specialize for attribute accesses. The only change we'd need to do is thatLOAD_ATTR
now needs to pushNULL
onto the stack, but we're on that path anyways (withLOAD_GLOBAL
pushingNULL
for calls as well. We also need to ensure that inline_cache_entries(LOAD_METHOD) >= inline_cache_entries(LOAD_ATTR)My main concern is that this will break certain assumptions by code introspection tools. However, I don't know what's the extent.
Another obvious downside is that we may lose the unbound method optimisation. That's roughly a 20% speedup lost.
LOAD_ATTR
specialization itself is a 20% gain though so it might balance out. Also I don't expect many unbound methods in such scenarios.Beta Was this translation helpful? Give feedback.
All reactions