aio-libs / multidict / 37793096165

86%

push

github

Reserve room for update() and merge() only when keys are added (#1755)

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

## What do these changes do?

`update()` and `merge()` reserved room for every item of their argument
before the batch, so an update of keys already present rebuilt the table
on every call, about 15% of its cost. Like `dict.update()`, they now
grow up front only a table that could not hold the argument even empty,
or one with holes from deletions (a rebuild inside the batch would have
to keep them). Otherwise the first added key makes room for the whole
batch: `update_marks_t.reserve` carries the size, and the add path tests
`usable <= reserve`, which folds the pending check into the existing
full-table test. A rebuild during a batch now takes the compacting path
when the table has no holes, since compaction then keeps every index.

The pure-Python backend got the same sizing, so `sys.getsizeof()` still
agrees between the two.

## Are there changes in behavior for the user?

No, apart from a smaller table after an update of keys that were already
present.

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

No; it is a sizing rule in `md_reserve_batch()` plus one field in
`update_marks_t`.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt` N/A
- [x] Add a new news fragment into the `CHANGES/` folder
- [x] `make doc-spelling` passes and any new technical words are added
to `docs/spelling_wordlist.txt`

Drafted with Claude Code (Claude Opus 5.5); reviewed by @asvetlov.

<details>
<summary>Agent run details (optional, for reviewers)</summary>

Callgrind, `PYTHONHASHSEED=0`, per call with a 100-item argument (N=120
minus N=20 runs), base fb828e3f, CPython 3.14.7 and 3.14.7t:

| case | GIL md / ci | FT md / ci |
| --- | --- | --- |
| up... (continued)

832 of 1664 branches covered (50.0%)

Branch coverage included in aggregate %.

44 of 46 new or added lines in 2 files covered. (95.65%)

9706 of 10588 relevant lines covered (91.67%)

1.83 hits per line