aio-libs / multidict / 35906736075

87%

push

github

Give istr its own vectorcall (#1537)

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

## What do these changes do?

`istr(x)` went through `type_call()`, which packs the argument into a
tuple, and `istr_new()` then unpacked it again with
`PyArg_ParseTupleAndKeywords()`. The one-argument form, which is how an
`istr` gets built in practice, needs none of that.

`istr` now has a `tp_vectorcall` that handles that form directly, and
leaves `istr()` and the `encoding` / `errors` signature to a cold path
that rebuilds the tuple and calls `istr_new()` as before. Subclasses are
unaffected: CPython does not copy `tp_vectorcall` to a subclass, so
`class Sub(istr)` still goes through `type_call()` and `tp_new`.

There is one cost, and it is not in the `istr` path. `getall()` runs
nine
more instructions per call, because the added code moves where the
compiler draws its inlining line and `md_calc_identity()` lands out of
line in `_md_get_all_locked()`. The multidict side of the callgrind
profile is otherwise identical, and no attempt to place the new code
differently moved that number.

C-extension-only. The pure-Python `istr` is a plain `str` subclass with
no constructor of its own, so there is nothing to mirror there.

## Are there changes in behavior for the user?

No. Every constructor form was compared against `master` case by case,
including the `encoding` and `errors` arguments, the keyword forms, the
error messages for bad arguments, subclasses, `copy` and `pickle`; the
output is identical.

## 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
- [x] Documentation reflects the changes <!-- N/A, no user-visible API
change -->
- [ ] 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 tech... (continued)

765 of 1530 branches covered (50.0%)

Branch coverage included in aggregate %.

25 of 29 new or added lines in 1 file covered. (86.21%)

7246 of 7636 relevant lines covered (94.89%)

1.9 hits per line