Optimize reference counting overhead of LOAD_FAST variants
#130704
Labels
interpreter-core
(Objects, Python, Grammar, and Parser dirs)
performance
Performance or resource usage
type-feature
A feature request or enhancement
Comments
mpage
added
type-feature
mpage
added a commit
that referenced
this issue
Apr 1, 2025
Optimize `LOAD_FAST` opcodes into faster versions that load borrowed references onto the operand stack when we can prove that the lifetime of the local outlives the lifetime of the temporary that is loaded onto the stack.
seehwan
pushed a commit
to seehwan/cpython
that referenced
this issue
Apr 16, 2025
Optimize `LOAD_FAST` opcodes into faster versions that load borrowed references onto the operand stack when we can prove that the lifetime of the local outlives the lifetime of the temporary that is loaded onto the stack.
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Apr 29, 2025
After pythongh-130704, the interpreter replaces some uses of `LOAD_FAST` with `LOAD_FAST_BORROW` which avoid incref/decrefs by "borrowing" references on the interpreter stack when the bytecode compiler can determine that its safe. This change broke some checks in C API extensions that relied on `Py_REFCNT()` of `1` to determine if it's safe to modify an object in-place. Objects may have a reference count of one, but still be referenced further up the interpreter stack due to borrowing of references. This provides a replacement function for those checks. `PyUnstable_Object_IsUniqueTemporary` is more conservative: it checks that the object has a reference count of one and that it exists as a unique strong reference in the interpreter's stack of temporary variables in the top most frame. See also: * numpy/numpy#28681
colesbury
added a commit
that referenced
this issue
May 2, 2025
…h-133170) After gh-130704, the interpreter replaces some uses of `LOAD_FAST` with `LOAD_FAST_BORROW` which avoid incref/decrefs by "borrowing" references on the interpreter stack when the bytecode compiler can determine that it's safe. This change broke some checks in C API extensions that relied on `Py_REFCNT()` of `1` to determine if it's safe to modify an object in-place. Objects may have a reference count of one, but still be referenced further up the interpreter stack due to borrowing of references. This provides a replacement function for those checks. `PyUnstable_Object_IsUniqueReferencedTemporary` is more conservative: it checks that the object has a reference count of one and that it exists as a unique strong reference in the interpreter's stack of temporary variables in the top most frame. See also: * numpy/numpy#28681 Co-authored-by: Pieter Eendebak <[email protected]> Co-authored-by: T. Wouters <[email protected]> Co-authored-by: mpage <[email protected]> Co-authored-by: Mark Shannon <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature or enhancement
Proposal:
LOAD_FASTand its super instruction form are the most frequently executed bytecode instructions in most Python programs (they represent ~20% of dynamic instruction frequency on the benchmark suite). While they are very cheap (they're just an incref and a push to the stack), they are not free. If we can prove that the reference in the frame outlives the reference that is loaded on the stack we can use a cheaper variant ofLOAD_FASTthat loads an appropriately tagged borrowed reference onto the operand stack, thereby avoiding the incref/decref.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
faster-cpython/ideas#700
Linked PRs
LOAD_FAST{_LOAD_FAST}#130708The text was updated successfully, but these errors were encountered: