I have commits to do that in my draft branch (https://github.com/python/cpython/compare/main...cmaloney:cpython:ac_vectorcall_v1?expand=0); can pull them into this branch if that would be easier / better to review. This generally produces code that is as fast or faster than the hand-written ones currently (full benchmarking in: #87613 (comment))

Added commits moving enum.c (reversed, enumerate) and tuple to the new decorator. enum.c had comments pointing to this issue and covers positional + keyword arguments. tuple uses the "zero arg" optimization and has no keyword args. None of those cases use the __init__ code; only cases of that are the new bytearray or list which is otherwise very similar to tuple. Hoping those serve as a good sample for what the code generation looks like relative to the handwritten while iterating; happy to include more in this PR if desired.

I will take a look at this PR til end of this week.

happy to include more in this PR if desired.

I would like to suggest you at least to think about complexobject.c. Based on benchmarks for the float pr (#22432) I would expect a good performance boost (maybe not 1.5x, but more than from freelist addition).

Yes, this case seems to be already covered by the enum.c example (kwargs).

On another hand, the complex class has special hacks to support multiple signatures (complex('123') is allowed, while complex(real='123') - not). Maybe it's not the only case, but I can't find quickly others across the CPython codebase. I suspect that AC magic will not work in this case and we will need some workarounds somewhere (well, maybe just one hand-written case). Though, it would be great if you disprove this hypothesis.

This generally produces code that is as fast or faster than the hand-written ones currently (full benchmarking in: #87613 (comment))

Still, there are some regressions, e.g. int(str). Could you explain this difference?

I also suggest you to try pyperformance on this.

I would like to suggest you at least to think about complexobject.c. Based on benchmarks for the float pr (#22432) I would expect a good performance boost (maybe not 1.5x, but more than from freelist addition).

Will implemnt it in my draft branch this week. As part of developing this PR I added Vectorcall Protocol support to bytes (cmaloney@f5c7b7c) and bytearray (cmaloney@7de2ab7). With just two small changes: 1. add @vectorcall, 2. set .tp_vectorcall construction is 1.09x to 1.23x faster. Multiply that speedup across the many AC implemented types without vectorcall construction and I definitely get excited.

Still, there are some regressions, e.g. int(str). Could you explain this difference?

The int hand written vectorcall implementation, long_vectorcall, is a particularly elegant switch:

That switch specializes 1-argument to call PyNumber_Long instead of long_new_impl which matches a very similar performance delta I investigated yesterday in the hand written vectorcall for str. Worried the hand written is faster because the compiler optimizer is doing clever things around the switch form. Adding support for a one_arg special case will need more code in the AC implementation to handle. Overall not sure it's actually worth replacing the hand written int vectorcall with an AC generated version for.

I'm comparing to the handwritten because I want @vectorcall when people try it out on a type they care about to be as good as I can get it. Adding to two types without vectorcall construction, bytes and bytearray, it provides a measurable speedup for a two-line code change. I think correctness of generated code, maintainability of the new decorator, and providing a speedup for types with no vectorcall today is a lot of benefit even if it's not quite as fast as hand written expert code. If adopting the new decorator on an AC type is really low-cost for a significant performance gain that will lead to speedy adoption and a speedier CPython.

I also suggest you to try pyperformance on this.

Will run on this PR as it exists currently.

I can also run on my draft branch but not sure that will give a clear signal as it migrates every hand-written vectorcall even if it makes them slower. Ideally to me would be able to figure out what types are commonly constructed in pyperformance benchmarks so I can make a draft branch adding vectorcall support to those. Not sure what would be the most important set of types to migrate before running pyperformance.

Did you consider adding this implicitly if supported, instead of making it opt-in? Disclaimer: I didn't take a look at the implementation yet.

Multiply that speedup across the many AC implemented types without vectorcall construction and I definitely get excited.

Yes, I hope that can mitigate speed regression with Decimal's since v3.13. Edit: no, this doesn't help too much.

Overall not sure it's actually worth replacing the hand written int vectorcall with an AC generated version for.

In any case, this will happen on case-by-case basis (this pr should include minimal set of such examples). BTW, here my results for this pr + c14c173.

Benchmark code: cmaloney@ddcd3b6, run with --rigorous
Configure options: ./configure --enable-optimizations --with-lto --with-static-libpython
Host: 64-bit Debian (Trixie)
Compiler: GCC 14.2.0

Benchmark hidden because not significant (9): list(), list_subclass, float(), float(str), bytearray(), tuple(list), int(), reversed(list), enumerate(list)

With default ./configure:

# vectorcall-bench.py

import pyperf

runner = pyperf.Runner()
bench_cases = ['1<<7', '1<<38', '1<<300', '1<<3000']

for c in bench_cases:  # XXX: bigger sample
    i = eval(c)
    bn = f'int({c})'
    runner.bench_func(bn, int, i)
for c in bench_cases:
    i = eval(c)
    s = str(i)
    bn = f'int({c!r})'
    runner.bench_func(bn, int, s)

I think correctness of generated code, maintainability of the new decorator, and providing a speedup for types with no vectorcall today is a lot of benefit even if it's not quite as fast as hand written expert code.

I agreed. But if auto-generated code catch major patterns for current hand-written functions - it will be great.

I can also run on my draft branch

No, I don't think it does make much sense with a lot of conversions to AC magic in one shot.

Did you consider adding this implicitly if supported, instead of making it opt-in? Disclaimer: I didn't take a look at the implementation yet.

My leaning is explicit at least to start. I think that provides a good path for gradual adoption / testing / rollout (hopefully in the 3.15 timeframe). I'd really like at least an alpha which reaches wider testing with a couple common types (ex. bytes) moved to make sure there aren't unanticipated tradeoffs or issues.

This PR is very promising! Great work.

Added a vectorcall test to the _testclinic module and a new VectorcallFunctionalTest which exercises the emitted __init__ and __new__

Debating if a hypothesis test of "does this parse the right args + kwargs" would provide value for the complexity.

Full pyperformance numbers on the current PR below. No cases stand out to me / all seems to be within noise for my machine. That is enumerate, reversed, and tuple don't seem to change performance going from hand written to the auto-generated as expected.

Not sure what will make this easier to review. I am happy to resolve the merge conflict anytime but also don't want to disturb in-process reviews. I am thinking of scoping this down to just _testclinic + the core implementation to reduce risk. Then there should be no performance (or behavior) changes in existing code as this just adds support and tests to AC but no user visible usage. With that setup can add to one type at a time in very focused PRs with micro benchmarks + pyperformance.

pyperformance comparison: 3484ef6 (just before) vs HEAD (vectorcall clinic)

Platform: Linux-6.19.9-arch1-1-x86_64-with-glibc2.43 | 32 logical CPUs
Baseline: 3484ef60 (2026-03-21 19:46–20:31) | Changed: HEAD 3698a32d (2026-03-21 20:34–21:20)

This PR is stale because it has been open for 30 days with no activity.