aio-libs / multidict / 35966702630

87%

push

github

Skip zeroing hash table entries that are about to be overwritten (#1540)

<!-- Thank you for your contribution! -->

## What do these changes do?

Two places built a table's entries array twice over.

`md_clone_from_ht()` allocated with a raw `PyMem_Malloc()` and then
memcpy'd the source over every byte, so it neither used the pool nor
needed the initialisation `htkeys_new()` would have done. It now takes
uninitialised storage from the same pool, which skips both memsets.

`_md_resize()` allocated a zeroed entries array and then wrote the front
of it from the old table, so everything it copied had just been zeroed
for nothing. The new table now comes back untouched and only the part
past the copy is zeroed. The count comes from the copy itself rather
than from `md->used`: the two agree, and there is an assert saying so,
but taking it from the copy means a table can never be published over
entries nothing has written, which `ASSERT_CONSISTENT()` would read.

Neither memset can simply be shortened to the used prefix instead.
`_md_resize()` zeroes `oldkeys->nentries` before retiring while the
entries still hold stale non-owning pointers, so a table arriving at
`_md_free_retired()` from a resize reports no dirty entries and has
them; and `ASSERT_CONSISTENT()` reads every entry a table has room for,
not just the used prefix.

The resize half needs no pool and is the only part that moves on a
free-threaded build.

## Are there changes in behavior for the user?

No. Faster copying and resizing, nothing observable otherwise.

## Is it a substantial burden for the maintainers to support this?

No. The byte count of a table is now derived in one place,
`htkeys_alloc_size()`, from `log2_size` alone, with `htkeys_sizeof()`
reading the same number back off an existing table under an assert that
the two agree.

## Related issue number

None.

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the... (continued)

767 of 1534 branches covered (50.0%)

Branch coverage included in aggregate %.

11 of 11 new or added lines in 1 file covered. (100.0%)

7386 of 7784 relevant lines covered (94.89%)

1.9 hits per line