GH-107596: Specialize str[int] - #107597
Conversation
Sorry, something went wrong.
| PySlice_Check(sub) ? SPEC_FAIL_SUBSCR_TUPLE_SLICE : SPEC_FAIL_OTHER); | ||
| goto fail; | ||
| } | ||
| if (container_type == &PyUnicode_Type) { |
There was a problem hiding this comment.
Would it be a good idea to check if the string is all ASCII, so we don't immediately deoptimise in that case? Or just support all characters by calling unicode_char in the opcode case, it's the last branch anyway.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, I think I'll just change the specialization to only support ASCII strings, rather than bothering with other widths. It's quick and easy to check, since strings know their encoding.
Sorry, something went wrong.
|
Well, I think I know which new benchmark is responsible for this showing up so prominently in the failure stats... I'm going to modify this to only support ASCII strings, and see if that further improves things. |
Sorry, something went wrong.
|
I'm going to revert that last change. Turns out the TOML benchmark that's hitting this so hard is indeed getting mostly ASCII characters out of "barely-Unicode" strings. So the original code is probably fine. |
Sorry, something went wrong.
|
I'm happy with the benchmarks and stats. |
Sorry, something went wrong.
This handles cases where a string (with any internal representation) is indexed by a medium nonnegative integer, resulting in an ASCII character.
Running the benchamarks/stats now...