Skip to content

Conversation

@cocolato
Copy link
Contributor

@cocolato cocolato commented Feb 8, 2026

When the tier 2 optimizer can determine the type of the container being sliced, _BINARY_SLICE can be replaced with a specialized micro-op that bypasses the PySliceObject allocation entirely.

This PR implements scalar replacement of BINARY_SLICE by add new tier2 op _BINARY_SLICE_LIST, _BINARY_SLICE_TUPLE, and _BINARY_SLICE_UNICODE.

@cocolato
Copy link
Contributor Author

cocolato commented Feb 8, 2026

I think the tests failure that occurred is unrelated to the PR.

Copy link
Member

@Fidget-Spinner Fidget-Spinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty close, thanks!

@Fidget-Spinner
Copy link
Member

You forgot to add the new recorder to BINARY_SLICE macro op

Copy link
Member

@Fidget-Spinner Fidget-Spinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm just one comment and add news please

PySlice_AdjustIndices(PyUnicode_GET_LENGTH(container_o), &istart, &istop, 1);
res_o = PyUnicode_Substring(container_o, istart, istop);
}
DECREF_INPUTS();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should split this into the POP_TOP POP_TOP form, can you please do that in a follow up PR?

@Fidget-Spinner
Copy link
Member

Actually I've changed my mind. Can you please open a PR to convert BINARY_SLICE to the POP_TOP form please? Then after we merge that PR we can update this one

Copy link
Member

@Fidget-Spinner Fidget-Spinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave the DECREF_INPUTS alone for now and try to remove it in a future PR.

The code has repeated instances that should be factored out to a micro-op

@Fidget-Spinner
Copy link
Member

This is pretty close, I'm going to push some changes in, then wait a day to see if Mark has any objections tomorrow.

@cocolato
Copy link
Contributor Author

cocolato commented Feb 8, 2026

Thanks for your guidance!

1. We cannot exit after unpacking indices, as the stack contains tagged ints now which may lead to a crash. We must insert a guard for the type before unpacking indices.
2. It is possible for an indice to not fit in a tagged int, in which case we must deopt.
3. Recorded values do not always mean that that's the actual type we will see at runtime. So we must guard on that as well.
@Fidget-Spinner
Copy link
Member

@cocolato please check out the latest commit and the extended commit message for the bugs fixed. Thanks!

@Fidget-Spinner
Copy link
Member

add_int.py

def testfunc(n):
    data = [1, 2, 3, 4, 5]
    a, b = 1, 3
    for _ in range(n):
        x = data[a:b]
    return x

testfunc(50000000)

Results using hyperfine:

Summary
  PYTHON_JIT=1 ./python ../add_int.py ran
    1.12 ± 0.02 times faster than PYTHON_JIT=0 ./python ../add_int.py

So we made it >10% faster. Nice!

@cocolato
Copy link
Contributor Author

cocolato commented Feb 9, 2026

@cocolato please check out the latest commit and the extended commit message for the bugs fixed. Thanks!

LGTM! Thanks again for the fix, I learned a lot from it.

Results using hyperfine:

This is my first time learning about this tool, and it looks great. In the past, when I needed to run benchmarks locally, timeit was somewhat inaccurate, and pyperformance was a bit too heavy.

@cocolato
Copy link
Contributor Author

cocolato commented Feb 9, 2026

At the same time, I've noticed that when set PYTHON_OPT_DEBUG=5 is enabled, DUMP_UOP currently only outputs the first ADDED uop. I'll fix this in other PR.

Copy link
Member

@markshannon markshannon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this.
This looks sound, but there are some inefficiencies.

Beware the size of uops. They will be converted to machine code, so keeping code size down is important for performance.

}
}

op(_UNPACK_INDICES, (container, start, stop -- container, sta, sto)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

start and stop may well be constants. Slices like [:n] and [n:] are quite common, so this can be optimized, popping the None and replacing it with tagged(0) for start, or tagged(MAX) for the end.

If both values are constant we can eliminate the _UNPACK_INDICES. If only one is constant, then we can replace _UNPACK_INDICES with a non-negative compact int guard and tagging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this should be implemented after #144569 (comment). I will open other PR to do this.

@bedevere-app
Copy link

bedevere-app bot commented Feb 9, 2026

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@cocolato cocolato changed the title gh-144569: Scalar replacement of BINARY_SLICE for list, tuple, and unicode gh-144569: Avoid creating temporary objects in BINARY_SLICE for list, tuple, and unicode Feb 10, 2026
@cocolato
Copy link
Contributor Author

Thank you for your review and corrections! I have made the requested changes; please review again.

@bedevere-app
Copy link

bedevere-app bot commented Feb 10, 2026

Thanks for making the requested changes!

@markshannon: please review the changes made to this pull request.

@bedevere-app bedevere-app bot requested a review from markshannon February 10, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants