This looks OK to me, pending benchmarking. It means we will do one or two extra NULL writes to localsplus entries that are about to get written again with a value, in some hot paths that use . (This could be avoided with an extra integer argument.) Will wait and see what Mark thinks.

These are benchmarking results from before I changed to pass the int arg:
https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20230104-3.12.0a3%2B-e73d0cf/bm-20230104-linux-x86_64-iritkatriel-InitializeHeader-3.12.0a3+-e73d0cf-vs-base.md

(overall x0 faster).

I will rerun with the last change.

The results for this version are here: https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20230105-3.12.0a3%2B-d501577/bm-20230105-linux-x86_64-iritkatriel-InitializeHeader-3.12.0a3+-d501577-vs-base.md

0x00 slower.

Might as well go with the faster version.

You don't think this is noise?

I created #100775 with the arg removed, will run the benchmark one more time.

I created #100775 with the arg removed, will run the benchmark one more time.

Now that one came 0x0% slower as well. I think this is noise, we should just go with whichever.

I'm off to my humus fest soon. Feel free to merge this or #100775 and close the other.

The result of the last run are here: https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20230105-3.12.0a3%2B-94fa28c/bm-20230105-linux-x86_64-iritkatriel-InitializeHeader_noa-3.12.0a3+-94fa28c-vs-base.md

I'm merging this, as the performance difference with this and #100775 is in the noise, and this seems the more efficient design.