aio-libs / multidict / 37110008949

86%

push

github

Keep d[key] = v's duplicate collector off the stack (#1650)

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

## What do these changes do?

`d[key] = v` carried a `reflist_t` with 15 inline slots in its frame on
every call, though only later duplicates of the key ever need it. The
replaced key and value now go into two locals released after the
critical section, and the collector for duplicates is allocated on the
heap the first time one turns up.

C extension only; the pure-Python implementation has no equivalent.

Callgrind driver, Ir per op vs `73e8bbd8`:

| row | GIL MultiDict | GIL CIMultiDict | FT MultiDict | FT CIMultiDict
|
| --- | --- | --- | --- | --- |
| setitem_replace | -4.4% | -4.9% | -3.9% | -4.1% |
| setitem_insert | -2.8% | -2.5% | -1.1% | -0.9% |
| setitem_istr | -4.6% | -5.7% | -1.2% | -4.7% |

Every other row is within 0.4%, except GIL MultiDict `getitem_istr`,
whose code is unchanged and which swings by about 3% in either direction
between driver builds; a direct bracketed harness put it at +0.04%. An
FT-only `ALWAYS_INLINE` on `_key_to_identity_cs` was needed before #1651
to keep `delitem` flat; after #1651 it no longer pays off and was
dropped.

Wall clock on an idle box (measured before merging #1651/#1653), base
and fix alternating on one pinned P-core, 15 rounds, median of the
per-round deltas (`dict` in the same processes stayed within 3%):

| row | GIL MultiDict | GIL CIMultiDict | FT MultiDict | FT CIMultiDict
|
| --- | --- | --- | --- | --- |
| setitem_replace | -11.4% | -12.4% | -9.0% | -5.8% |
| setitem_insert | -2.9% | -8.9% | -2.1% | -5.7% |
| setitem_istr | -3.1% | -6.3% | +1.8% | -6.4% |

`delitem`, `add`, `getitem_hit`, `getitem_istr` and `ctor_items` came
out within their own interquartile range of zero on both builds.

## 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 wr... (continued)

791 of 1582 branches covered (50.0%)

Branch coverage included in aggregate %.

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

9193 of 10037 relevant lines covered (91.59%)

1.83 hits per line