[skirpichev]

This shows almost no effect on "official" pyperformance benchmarks (see python/pyperformance#473):

decimal_pi: Mean +- std dev: [ref] 1.92 sec +- 0.02 sec -> [patch] 1.89 sec +- 0.02 sec: 1.02x faster

Benchmark hidden because not significant (2): decimal_factorial, telco

Geometric mean: 1.01x faster

But on micro-benchmarks it show some speedup:

Decimal(0): Mean +- std dev: [ref-micro] 591 ns +- 10 ns -> [patch-micro] 513 ns +- 12 ns: 1.15x faster
Decimal(123): Mean +- std dev: [ref-micro] 596 ns +- 22 ns -> [patch-micro] 515 ns +- 26 ns: 1.16x faster
Decimal('123'): Mean +- std dev: [ref-micro] 764 ns +- 16 ns -> [patch-micro] 677 ns +- 24 ns: 1.13x faster

Geometric mean: 1.15x faster

(Default ./configure options, gcc 14.2)

Details

# bench.py
import pyperf
from decimal import Decimal

runner = pyperf.Runner()
for x in [0, 123, '123']:
    h = f"Decimal({x!r})"
    runner.bench_func(h, Decimal, x)

• Issue: Speed regression in the decimal module due to using heap types #144650

[cmaloney]

#157968 may help with the build failures (changes how the assert works which should make it better across module boundaries)

[skirpichev]

Thanks. The Decimal is only possible candidate being a heap type in the stdlib. That was worked before in skirpichev#18

[cmaloney]

👍 hopefully will get more of these landed soon :). str and list still need some special work for stable performance over the change which I'm still root causing (likely compiler inlining vs. existing hand inlining). If there are ways I can help enable / particular edge cases you find let me know. Otherwise planning to make PRs as I have time + performance results for existing cases across the codebase (int, float, str, list, bytes, bytearray, bool, filter, set, frozenset are on my radar).

[skirpichev]

CC @vstinner, does it make sense for you?

Edit: N.B., this depends on #157968.

[vstinner]

Did you close it because you consider that it's not worth it?

[skirpichev]

I think it still worth it, assuming micro-benchmarks. It's for free, anyway.

But it's on top of #157968. If you are ok, I'll reopen this one that pr (or some its alternative) will be merged.

[vstinner]

Benchmark results were posted 1 month ago, but the PR changed in the meanwhile. Would it be possible to re-run benchmarks on the latest PR version?

[vstinner]

Is it useful to mark the function as "inline"? Does it impact performance?

[vstinner]

See also #73487 which converted many Decimal methods to vectorcall using Argument Clinic.

[skirpichev]

#158207 (comment) were posted 1 month ago, but the PR changed in the meanwhile. Would it be possible to re-run benchmarks on the latest PR version?

In fact, you can see that benchmarks already updated. Not so much, as before. #156034 shows better numbers.

Now included telco benchmark.

Is it useful to mark the function as "inline"? Does it impact performance?

This is something that was suggested in #160115.

You can compare my previous benchmark run. IMO, the difference looks more or less as a noise:
#160115 (comment)

Not sure if this worth reversion. That function used only once, anyway.

[cmaloney]

I don't mind the inline keyword, it's a compiler hint that is largely ignored (which is why forceinline exists..). Compilers decided people perf tested and added then never maintained ><. In this case PyDecType_FromObjectExact inlines into the _new_impl with or without it in the experimentation I've done. It doesn't inline into the vectorcall handler because there are two callers of _new_impl and the compiler decides not to proceed.