[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: New changeset 0f7b0b397e12514ee213bc727c9939b66585cbe2 by Victor Stinner in branch 'master': bpo-29735: Optimize partial_call(): avoid tuple (#516) https://github.com/python/cpython/commit/0f7b0b397e12514ee213bc727c9939b66585cbe2 -- _

[issue29735] Optimize functools.partial() for positional arguments

Changes by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: I measured that my patch (pull request) increases the stack usage of 64 bytes per partial_call() call. I consider that it's accepted for a speedup between 1.12x faster and 1.25x faster. Attached partial_stack_usage.py requires testcapi_stack_pointer.patch of

[issue29735] Optimize functools.partial() for positional arguments

Serhiy Storchaka added the comment: Nice results. You made a great work for decreasing C stack consumption. It would be sad to lose it without good reasons. Could you please compare two variants, with and without small stack? -- ___ Python tracker

[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: > What about C stack consumption? Is not this increase it? Yes, my optimization consumes more C stack: small_stack allocates 80 bytes on the stack (for 5 positional arguments). Is it an issue? -- ___ Python tracker

[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: bench_fastcall_partial.py: more complete microbenchmark. I rewrote my patch: * I added _PyObject_HasFastCall(callable): return 1 if callable supports FASTCALL calling convention for positional arguments * I splitted partial_call() into 2 subfunctions: partial_

[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: > If the underlying function doesn't support fast call, and both args and > pto->args are not empty, patched partial_call() makes one unneeded copyings. The simple workaround is to revert changes using FASTCALL in partial_call(). But for best performances, it

[issue29735] Optimize functools.partial() for positional arguments

Serhiy Storchaka added the comment: If the underlying function doesn't support fast call, and either args or pto->args are empty, partial_call() makes two unneeded copyings. Arguments are copied from a tuple to the raw array and from the array to new tuple. This is what the current code does,

[issue29735] Optimize functools.partial() for positional arguments

Serhiy Storchaka added the comment: What about C stack consumption? Is not this increase it? Since nested partial()`s are collapsed, you need to interlace them with other wrapper for testing. def decorator(f): def wrapper(*args): return f(*args) return wrapper def f(*args): pa

[issue29735] Optimize functools.partial() for positional arguments

Changes by STINNER Victor : -- nosy: +ncoghlan, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue29735] Optimize functools.partial() for positional arguments

STINNER Victor added the comment: functools.partial() is commonly used in the the asyncio module. The asyncio doc suggests to use it, because of deliberate limitations of the asyncio API. -- nosy: +inada.naoki, serhiy.storchaka, yselivanov ___ Python

[issue29735] Optimize functools.partial() for positional arguments

Changes by STINNER Victor : -- pull_requests: +425 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue29735] Optimize functools.partial() for positional arguments

New submission from STINNER Victor: The pull request makes functools.partial() faster for positional arguments. It avoids the creation of a tuple for positional arguments. It allocates a small buffer for up to 5 parameters. But it seems like even if the small buffer is not used, it's still fas