[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

STINNER Victor added the comment: Serhiy Storchaka: > As for update_one_slot() see also issue5322 and issue25731. Oh, thanks for the pointers! Now I understand much better these bugs. I'm quite sure that they are still flaws in this code when a type is modified after PyType_Ready(), like

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

Serhiy Storchaka added the comment: As for update_one_slot() see also issue5322 and issue25731. -- ___ Python tracker ___

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

STINNER Victor added the comment: While they are obvious speedup on microbenchmarks, it doesn't speedup "macro" benchmarks from performance as much as I expected. The changes required in typeobject.c to support "tp_new or tp_fastnew" and "tp_init or tp_fastinit" are large and very complex.

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

Roundup Robot added the comment: New changeset 8feb6a5ce4c6 by Victor Stinner in branch 'default': Issue #29358: Add postcondition checks on types https://hg.python.org/cpython/rev/8feb6a5ce4c6 -- nosy: +python-dev ___ Python tracker

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

STINNER Victor added the comment: I implemented more optimizations: * type_call() uses FASTCALL * object_new() and object_init() use FASTCALL * _asyncio.Future new & init use FASTCALL As a result, create an _asyncio.Future is now 1.45x faster: haypo@smithers$ ./python -m perf timeit -s

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

STINNER Victor added the comment: First benchmark result on the fast_init compared to the default branch. Warning: the patch is still a WIP, there are maybe performance issues (in this case, this benchmark should help to identify them). --- haypo@speed-python$ python3 -m perf compare_to

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

Josh Rosenberg added the comment: So just to be clear, the issue with non-string or non-unique keywords is purely about performance, right, not correctness/non-crashiness? Non-string keywords, while technically accepted by CPython, are at best barely legal by the language standard. The

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

Yury Selivanov added the comment: Great. Can you share the Richards benchmark results? It specifically stresses class instantiation, so we should be able to see the improvement. -- ___ Python tracker

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

STINNER Victor added the comment: Serhiy Storchaka: "Calling _PyStack_AsDict() with non-string or non-unique keywords means that the var-keyword argument was first unpacked to arrays of keyword names and values and then converted back to a dict. Seems something is done non-efficiently."

[issue29358] Add tp_fastnew and tp_fastinit to PyTypeObject, 15-20% faster object instanciation

New submission from STINNER Victor: After #29259 "Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects", the two last slots which still use the (args: tuple, kwargs: dict) calling convention are tp_new and tp_init, two major slots to instanciate