@skirpichev Would you like to provide benchmark enhancement for this change?

Oops, I just forgot to post one. Description updated.

Please share the pyperformance benchmark results.
I'm not sure how often complex types are used in real-world workloads.
Microbenchmarks like this might suggest adding every built-in type to the freelist, but I don't think that's what we want.
Most of the types we've added so far are commonly used in loop-based operations.

cc @Fidget-Spinner @encukou @eendebakpt

Please share the pyperformance benchmark results.

Well, it shouldn't be affected. This collection has no benchmarks for complex math at all:

$ git grep _E '[0-9.][jJ]|cmath|complex' pyperformance/data-files/benchmarks/||echo Oops
Oops

I'm not sure how often complex types are used in real-world workloads.

Probably less than floats, but not too much.

AFAICS, real-world workloads that don't use complex numbers will pay the price of:

• two unused words of memory
• the maintenance burden of a (I assume!) standard and unsurprising use of _Py_freelist

In applications that do use complex numbers, is it likely that they need to create/destroy them quickly?
IMO, an educated guess is enough to answer that, and if we've established that this is what freelists help with... I'd just trust Sergey here.

To review this I'll need to teach myself about Python's freelists; I can do that next week.

IMO, an educated guess is enough to answer that, and if we've established that this is what freelists help with... I'd just trust Sergey here.

I believe that we use pyperformance benchmark as the real world proxy. So if there is no benchmark for it, I am unsure. At least someone needs to share the benchmark for this. If not, people will add new PR for other built-in types with a microbenchmark, which would not be worth adding. We need criteria for this.

two unused words of memory

Yes, just a new empty _Py_freelists.

In applications that do use complex numbers, is it likely that they need to create/destroy them quickly?

That happens in every arithmetic operation.

Here is a benchmark with a simple sin() implementation:

# bench2.py
def mysin(z):
    i, lasts, s, fact, num, sign = 1, 0, z, 1, z, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i*(i-1)
        num *= z*z
        sign *= -1
        s += num/fact*sign
    return s
import pyperf
runner = pyperf.Runner()
runner.bench_func('mysin(1j)', mysin, 1j)
runner.bench_func('mysin(1+1j)', mysin, 1+1j)

To review this I'll need to teach myself about Python's freelists

You are not alone, this is new for me as well :D IIUC (see help topic), this technique is not something, allowed for external C extensions.

If not, people will add new PR for other built-in types with a microbenchmark

I doubt we have too much built-in types. Being a built-in type is a sign from the real world too ;-)

I see this as a PR that speeds up complex numbers, not “X% of Python's real-world usage”. And that's fine.

We need criteria for this.

Why shouldn't the criteria be “any small builtin type where typical usage needs many instances”?

If not, people will add new PR for other built-in types with a microbenchmark, which would not be worth adding.

Why not? What would be the downside of all such built-in types using freelists?