This is a great small change, especially if it ends up providing most of the benefit of #96446.

I'm running this PR on the Faster CPython team's standard benchmarking machine as well to get another data point (though I may not be able to report back until after the long weekend).

I measured only a 0.07% speedup on the pyperformance and pyston macrobenchmarks. I'm going to run this (and the baseline) again, because it's surprising it's so little. I don't want to imply that's an argument against this PR (and it's not really up to me anyway). Reproducibility of benchmarks in general, especially when the margins are so small, is an ongoing challenge we're all struggling with.

Yeah I think that even with some changes to make benchmarking more stable (bolt + longer bolt task) the systematic errors are around this level so I think it's hard to rely on the benchmarking numbers too much.

Sorry I'm not super familiar with the cpython workflow, is there anything I can do to help progress this through the "awaiting_merge" state?

This improvement is very small to users. I think we don't need news file for this.

$ ./python-nonzero2 -m pyperf timeit --duplicate 10 --compare-to ./python --python-names master:patched -s 'x=42' -- '(1,2,x)'
master: ..................... 29.1 ns +- 0.1 ns
patched: ..................... 29.3 ns +- 0.3 ns

Mean +- std dev: [master] 29.1 ns +- 0.1 ns -> [patched] 29.3 ns +- 0.3 ns: 1.01x slower

$ ./python-nonzero2 -m pyperf timeit --duplicate 10 --compare-to ./python --python-names master:patched -s 'x=42' -- '(1,2,3,4,5,6,7,8,9,x)'
master: ..................... 56.0 ns +- 0.5 ns
patched: ..................... 55.5 ns +- 1.3 ns

Mean +- std dev: [master] 56.0 ns +- 0.5 ns -> [patched] 55.5 ns +- 1.3 ns: 1.01x faster

thanks!