aio-libs / multidict / 36683586330

86%

push

github

Reach an entry's identity, hash and neighbours through accessors (#1641)

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

## What do these changes do?

Every place that reads or writes an entry's identity or hash, indexes
into a table's entries, steps to a neighbouring entry, or sizes a copy
of entries now goes through a helper that takes the table the entry
belongs to: `htkeys_entry_at()`, `htkeys_entry_next()`/`_prev()`,
`htkeys_entry_index()`, `htkeys_entry_copy()`, `htkeys_entry_size()`,
`entry_identity()`/`entry_set_identity()`/`entry_identity_slot()`,
`entry_hash()`/`entry_set_hash()`, and the existing `load_identity()`,
`publish_identity()`, `reset_identity()`, `load_hash()` and
`store_hash()`, which gain the table argument. The key and the value
stay plain fields.

This prepares per-table entry layouts, selected by a small kind field in
the table the way CPython's `dk_kind` works. The planned layouts keep
the key and the value at the same offsets (`{key, value}` for a table
whose identity is derivable from the key, `{key, value, identity}`
otherwise, `{key, value, hash}` later for non-str keys), so only the
stride, the identity and the hash need to know the table. A prototype of
the 16-byte `{key, value}` layout for `MultiDict` with exact `str` keys
measured `d.copy()` 46% cheaper on GIL and 40% on FT, construction 14%
and 8%, with lookups unchanged, which is what the follow-up will
implement.

Nothing changes in the emitted code: the helpers ignore the table for
now. The allocation size in `_htkeys_alloc_size()` still uses
`sizeof(entry_t)`, since it is computed before a table exists; the
follow-up passes the kind there.

## Are there changes in behavior for the user?

No.

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

No. New code touching entries uses the helpers instead of the fields.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [ ] Unit tests for the changes exist (N/A: no behaviou... (continued)

788 of 1576 branches covered (50.0%)

Branch coverage included in aggregate %.

8945 of 9621 relevant lines covered (92.97%)

1.86 hits per line