aio-libs / multidict / 37206750564

86%

push

github

Merge the bodies of __init__(), extend(), update() and merge() (#1673)

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

## What do these changes do?

`__init__()`, `extend()`, `update()` and `merge()` in `_multidict.c`
were four copies of the same structure: parse the arguments, pick one of
three locking arms by the type of the source, run the batch, flush the
watchers. They now share `_multidict_bulk()` and
`_multidict_bulk_locked()`, which removes about 140 lines from
`_multidict.c`.

Both helpers are `ALWAYS_INLINE` and take the operation as a constant,
so every entry point still compiles its own copy, as the
`check_inlining.py` rule from #1591 requires; the rule now names
`_multidict_bulk`.

`md_post_update()` moves out of line. Left to GCC it was inlined into
one arm of `update()`, and on free-threaded builds that took
`Py_NewRef()` out of the items iterator (+5 instructions per step) and
`list_getitem_ref()` out of the constructor loop. There is no way to
express a `NOINLINE` pin as a rule in `check_inlining.py`, so the
comment on the function carries the reason.

No behaviour change. The pure-Python implementation is not affected.

Measured with callgrind, before and after, on 3.14.7 and 3.14.7t, both
classes:

- `benchmarks/callgrind_driver.py --include-multidict-only`: every row
within 0.06%.
- The four entry points themselves, with a list, a dict, a multidict of
the same class, one of the other class, and keyword arguments only as
the source: all 80 cells between -0.12% and +0.29%. `merge()` is the
consistent mover, about +0.1% to +0.2% (roughly 20 to 30 instructions
per call) for the call to `md_post_update()`.

## Are there changes in behavior for the user?

No.

## 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 (the existing suite; no behaviour
change)
- [x] Documentation reflects the changes (N/A)
- ... (continued)

792 of 1584 branches covered (50.0%)

Branch coverage included in aggregate %.

9315 of 10167 relevant lines covered (91.62%)

1.83 hits per line