GH-96421: Don't keep local copies of first_instr
, names
and consts
in the interpreter.
#96847
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm struggling to get good performance numbers on this. An earlier run gave me a 4% speedup, which is clearly wrong.
However, we can look at the stats and deduce that this should speed things up.
first_instr
is never hot and can be computed cheaply asframe->f_code + OFFSET
. Caching it is pointless.The reasoning for
names
andconsts
is a bit more complex:names
andconsts
are spllled, two stores)names
, this PR costs two loads, or one load ifnames
is spilled.consts
, this PR costs two loads, or one load ifconsts
is spilled.The saving is small if
names
andconsts
are not spilled, but a compiler would be stupid not to spillnames
andconsts
on x86-64.So on RISC would expect a very small speedup, but on x86-64 we would expect a larger one. I would estimate in the 0.3-0.6% range.
Even if this results in a small slowdown, it should speedup #96319 and increase the potential benefit of adding
LOAD_CONST_IMMORTAL
Skipping news as this change is undetectable, even for a intrusive C extension.
Chesterton's Fence, a.k.a why were these values stored in local variables before?
These variables used to speed up CPython, even they no longer do:
first_instr
: Many jumps were absolute, sofirst_instr
was needed to make these jumps.names
:LOAD_ATTR
andLOAD_GLOBAL
neednames
. Thanks to PEP 659, these instructions (and their adaptive forms) are much less commonconsts
: The existence ofPOP_JUMP_IF_NONE
reduced the number ofLOAD_CONST
s a bit, andRETURN_GENERATOR
has increased the number of frame entry and exits. This may have tipped the balance, or maybe caching ofconsts
was misguided before.