You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Avoid creating temporary objects in BINARY_SLICE #144569
Note that we build a slice just for getitem, only to throw it away immediately after.
We can scalar replace the slice in BINARY_SLICE after recording the types. If we record the container type, we can call the slice dispatcher underneath directly without boxing the slice object. See for example BINARY_OP_SUBSCR_LIST_SLICE
We'd need to guard on the type recorded.
I propose to do this in the current optimizer pass rather than the partial evaluation pass, as this is just a simple optimization within a single op, while the PE pass can handle inter-instruction optimization.
@cocolato would you like to take this up? It should be a single peephole optimization so there isn't an issue about correctness. I can guide you on how to do it if you need help.
Pinging @markshannon. Since this is a single peephole optimization affecting a single instruction, I strongly feel it should be done in the current optimizer pass rather than the PE pass.
@cocolato would you like to take this up? It should be a single peephole optimization so there isn't an issue about correctness. I can guide you on how to do it if you need help.
Sure, I'd like to work on this. Thanks for reaching out!
I wouldn't describe this as "scalar replacement". We just want to avoid creating the temporary object within the one instruction.
One other thing that should be done to make this work well:
In the AST optimizer, 2-slices are converted to constants, which prevents this optimization working as well as it should.
deff(s):
returns[:1]
is compiled to:
LOAD_FAST_BORROW s
LOAD_CONST slice(None, 1, None)
BINARY_OP []
RETURN_VALUE
but is should be compiled to:
LOAD_FAST_BORROW s
LOAD_CONST None
LOAD_SMALL_INT 1
BINARY_SLICE
RETURN_VALUE
But take care to still convert 3-slices to constants:
The slice [::-1] should still be constant folded.
One other thing that should be done to make this work well:
In the AST optimizer, 2-slices are converted to constants, which prevents this optimization working as well as it should.
I think this would degrade Tier 1 performance. Do we really need to remove the constant optimization for 2-slices?
Activity
Fidget-Spinner commentedon Feb 7, 2026
@cocolato would you like to take this up? It should be a single peephole optimization so there isn't an issue about correctness. I can guide you on how to do it if you need help.
Pinging @markshannon. Since this is a single peephole optimization affecting a single instruction, I strongly feel it should be done in the current optimizer pass rather than the PE pass.
cocolato commentedon Feb 7, 2026
Sure, I'd like to work on this. Thanks for reaching out!
Fidget-Spinner commentedon Feb 7, 2026
@cocolato btw, I sent you an email!
[-]Scalar replacement of BINARY_SLICE[/-][+]Avoid creating temporary objects in BINARY_SLICE[/+]markshannon commentedon Feb 9, 2026
I wouldn't describe this as "scalar replacement". We just want to avoid creating the temporary object within the one instruction.
One other thing that should be done to make this work well:
In the AST optimizer, 2-slices are converted to constants, which prevents this optimization working as well as it should.
is compiled to:
but is should be compiled to:
But take care to still convert 3-slices to constants:
The slice
[::-1]should still be constant folded.markshannon commentedon Feb 9, 2026
In fact, it might be worth optimizing for the two constant slices
[:]and[::-1]as they are common idioms for copy and reverse.cocolato commentedon Feb 10, 2026
I think this would degrade Tier 1 performance. Do we really need to remove the constant optimization for 2-slices?
gh-144569: Avoid creating temporary objects in `BINARY_SLICE` for lis…
pythongh-144569: Avoid creating temporary objects in `BINARY_SLICE` f…
koxudaxi commentedon Aug 24, 2026
I'm looking at adding the same
BINARY_SLICEfast path for exactbytesas a follow-up to gh-144590.@cocolato, are you already working on this, or would you mind if I open a PR?
cocolato commentedon Aug 24, 2026
Sure, feel free to open a PR :)
koxudaxi commentedon Aug 24, 2026
Thanks! I opened #156318.
Merge branch 'main' into pythongh-144569-bytes-binary-slice
pythongh-144569: Test BINARY_SLICE type propagation