aio-libs / multidict / 34334407335

87%

push

github

Mark temporarily-removed entries via the hash's high bit, not -1 (#1426)

## What do these changes do?

Both backends marked a hash table entry invalid mid-update by
overwriting its hash with `-1`, then recomputed it from the identity to
restore it. This replaces that with a marker bit (the hash's high bit):
OR to set, AND to clear. That needs every hash non-negative first, so
hashes are folded once, right where computed (`& MAXSIZE` in Python,
inside `_unicode_hash()` in C). Restoring is then a bit-clear or a
direct assignment of an already-known value, never a recomputation.

Python's `hash()` is arbitrary precision, so a negative hash already
reads the high bit as set, which is why plain OR/AND needs the fold
first. C's `Py_hash_t` is fixed-width, so once folded, "is marked" is
just `entry->hash < 0`. `_unicode_hash()` folds only the value it
returns to multidict, never the unicode object's own cached hash slot
(shared process-wide). The ~15 `_unicode_hash(...) == -1` checks for a
genuine hash-computation error are untouched — a different,
CPython-standard meaning of `-1`.

Also adds a test for a related previously-uncovered path: a multidict
already at `update()`'s size-estimate cap needing a resize
mid-`update()`, which no existing test reached.

CodSpeed flagged a transient regression on `getall` partway through this
PR (a read-modify-write per marked entry where the `-1` sentinel only
wrote a constant); fixed by assigning known values directly and hoisting
the loop-invariant mark value out of the hot loops. Latest CodSpeed run
shows a **12.98% improvement**, including measurable C-extension
`getall` gains.

## Are there changes in behavior for the user?

No. Internal implementation detail of both backends.

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

No.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist (existing suite covers these
paths; added a te... (continued)

634 of 1268 branches covered (50.0%)

Branch coverage included in aggregate %.

47 of 47 new or added lines in 2 files covered. (100.0%)

4226 of 4443 relevant lines covered (95.12%)

1.9 hits per line