aio-libs / multidict / 36992438938

86%

push

github

Store a CIMultiDict of exact istr keys in the compact table (#1648)

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

## What do these changes do?

A `CIMultiDict` whose keys are all exact `istr` now uses the 16-byte
compact entry that #1644 introduced for a `MultiDict` of exact `str`
keys. The identity is the key's canonical form, read through the `istr`,
so the entry keeps only the key and the value. Any other key moves the
table to the full layout, keeping every index; the constructor picks the
layout from the first key it will get, or the full one when it also gets
keyword arguments, whose names are plain `str`, and `clear()` lets the
table start compact again. `extend()`, `update()` and `merge()` with
keyword arguments move a compact table while reserving room for the
batch, in one rebuild.

To keep `MultiDict` and str-keyed `CIMultiDict` flat while the table can
now take either layout under a `CIMultiDict`, every hot entry point
knows its class at compile time: `CIMultiDict` and `CIMultiDictProxy`
got their own slots and method tables, the bulk
`extend()`/`update()`/`merge()` paths are compiled once per class, and
the shared helpers take `ci` as a constant (asserted against `md->is_ci`
in debug builds). Lookups also stopped taking a reference to the
identity of an exact `str` or `istr` key; any other key is handled out
of line. `tools/check_inlining.py` gained rules for the new pins.

For an `istr`-keyed `CIMultiDict` of 200 keys the table is 45% smaller
(12032 to 6576 bytes), `copy()` costs 55 to 58% fewer instructions and
construction 14% (GIL) to 17% (FT) fewer. `d[key]` and `key in d` got 2
to 10% cheaper on GIL and 12 to 20% on FT for both classes. Rows that
got slower are listed below; the largest is `getitem_istr` on a
`MultiDict` (+4.8% on GIL), an `istr` key in a case-sensitive mapping,
which now takes the out-of-line path.

## Are there changes in behavior for the user?

No, apart from a smaller `__sizeof__()` for an `istr`-keyed
`CIMultiDic... (continued)

791 of 1582 branches covered (50.0%)

Branch coverage included in aggregate %.

62 of 149 new or added lines in 2 files covered. (41.61%)

9127 of 9947 relevant lines covered (91.76%)

1.84 hits per line