[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: > Oh, functools.partial.__call__() doesn't use fastcall yet. This issue reminded me that I didn't finish to optimize partial_call(): see issue #29735 for a minor optimization. -- ___ Python tracker

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: Oh wait, there was a major regression in my perf module :-( The --compare-to option was completely broken in the development branch (but it works for timeit --compare-to in the latest release). It's now fixed! So please ignore results of my previous comment.

[issue28243] Performance regression in functools.partial()

Serhiy Storchaka added the comment: Thanks Victor! -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: I just ran a microbenchmark, 3.6 compared to 3.5: haypo@smithers$ ./python -m perf timeit -s 'from functools import partial; f = lambda x, y: None; g = partial(f, 1)' 'g(2)' --duplicate=100 --compare-to ../3.5/python --python-names=3.5:3.6 3.5:

[issue28243] Performance regression in functools.partial()

Serhiy Storchaka added the comment: Can this issue be closed now? -- ___ Python tracker ___ ___

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: > Python 3.5: Median +- std dev: 423 ns +- 9 ns > Python 3.7: Median +- std dev: 427 ns +- 13 ns 0.9% slower on a microbenchmark is not really what I would call significant :-) But there is an underlying issue: when PGO+LTO is not used, Python 3.7 (and

[issue28243] Performance regression in functools.partial()

Serhiy Storchaka added the comment: With using all optimizations enabled the difference is much smaller if not disappeared. Python 3.5: Median +- std dev: 423 ns +- 9 ns Python 3.7: Median +- std dev: 427 ns +- 13 ns -- ___ Python tracker

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: "If revert c1a698edfa1b, the performance is returned to the level of 3.5." Oh, so using "fastcall" makes partial_call() slower? That's really something bad :-/ It would be nice if you can confirm using all optimizations enabled (PGO+LTO): ./configure

[issue28243] Performance regression in functools.partial()

Serhiy Storchaka added the comment: I meant just c1a698edfa1b. Median +- std dev: 441 ns +- 26 ns -- ___ Python tracker ___

[issue28243] Performance regression in functools.partial()

Serhiy Storchaka added the comment: If revert the issue27809 changes, the performance is returned to the level of 3.5. -- ___ Python tracker ___

[issue28243] Performance regression in functools.partial()

Changes by Emanuel Barry : -- nosy: +ebarry ___ Python tracker ___ ___ Python-bugs-list

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: Oh, functools.partial.__call__() doesn't use fastcall yet. So compared to Python 3.5, fastcall shouldn't explain a major performance difference. FYI I'm working on an extension of fastcall to also support fastcall calling convention for obj.__call__() ;-)

[issue28243] Performance regression in functools.partial()

STINNER Victor added the comment: The perf regression can be related to the new fastcall calling convention or the work in ceval.c (new 16-bit regular bytecode, new CALL_FUNCTION bytecodes). -- ___ Python tracker

[issue28243] Performance regression in functools.partial()

New submission from Serhiy Storchaka: There is 10% performance regression in calling functools.partial() in 3.6. $ ./python -m perf timeit -s 'from functools import partial; f = lambda x, y: None; g = partial(f, 1)' -- 'g(2)' Python 3.5: Median +- std dev: 452 ns +- 25 ns Python 3.6: Median