[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Here is rebased patch (just for history). Caching argtuple is not faster (or even slower) than using fast call. Regression in stack consumption is fixed in issue28858. Thanks Victor! -- resolution: -> fixed stage: -> resolved status: open ->

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: haypo: "status: open -> closed" Oops, it's a mistake, sorry. I only wanted to ask the question, not to close the issue. Serhiy Storchaka: "No, I'm referring to the crashing. The code that worked before your changes now are crashing." Sorry, I didn't notice

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: No, I'm referring to the crashing. The code that worked before your changes now are crashing. Please revert your changes and find a way to optimize a function calling without increasing stack consumption. -- resolution: fixed -> status: closed ->

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: > I opened a new issue #28852 to track this performance regression. So can I close again this issue? -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: Serhiy Storchaka: "Victor, your changes introduced a regression." I suppose that you are refering to sorted(list) which seems to be slower. Do you have a specific change in mind? As I wrote, it doesn't use a key function, and so should not be impacted by my

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Victor, your changes introduced a regression. -- resolution: fixed -> status: closed -> open ___ Python tracker ___

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: Serhiy: "I don't propose to commit this complicated patch, but these results can be used as a guide to the optimization of tuple creating. It is surprising to me that this patch has any effect at all." A new "fast call" calling convention was added to Python

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: I rewrote bench_builtins.py to use my new perf module. Python 3.7 is between 1.27x and 1.42x faster than Python 3.6, but sorted(list) is slower. I don't know why sorted(list) is slower. It doesn't use a key function, and so should not be impacted by FASTCALL

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Here is an example that shows increased stack consumption. With old code it counts to 74700, with the patch it counts only to 65400. Please revert your changes. -- Added file: http://bugs.python.org/file45725/stack_overflow.py

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: I think it would be better to optimize PyObject_CallFunctionObjArgs(). -- ___ Python tracker ___

[issue23507] Tuple creation is too slow

Roundup Robot added the comment: New changeset b9c9691c72c5 by Victor Stinner in branch 'default': Replace PyObject_CallFunctionObjArgs() with fastcall https://hg.python.org/cpython/rev/b9c9691c72c5 -- nosy: +python-dev ___ Python tracker

[issue23507] Tuple creation is too slow

Changes by Jakub Stasiak : -- nosy: +jstasiak ___ Python tracker ___ ___

[issue23507] Tuple creation is too slow

Demur Rumed added the comment: This code could be made to look a lot less hackish if the potential tuple reuse was abstracted by a PyTuple_UniqueOrNew(PyTuple) which returns its argument if REFCNT==1 otherwise allocates a tuple of the same size & returns that. It decrefs PyTuple if REFCNT !=

[issue23507] Tuple creation is too slow

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker ___ ___

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: reuse_argtuples_3.patch: rebased reuse_argtuples_2.patch. -- Added file: http://bugs.python.org/file42571/reuse_argtuples_3.patch ___ Python tracker

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: msg264009: Serhiy Storchaka "Could you compare filter(), map() and sorted() performance with your patch and with issue23507 patch?" Here you have the result of bench_builtins.py. The performance look to be the same, even if I expect better performance with

[issue23507] Tuple creation is too slow

STINNER Victor added the comment: Hi, I started to work on a new top-down approach avoiding completly temporary tuple/dict: "FASTCALL", issue #26814. As you may expect, the patch is much larger that Serhiy's patches attached to his issue, but IMHO the final code is much simpler: it doesn't

[issue23507] Tuple creation is too slow

Raymond Hettinger added the comment: Unassigning because I don't have an interest in going further down this path. I used this technique with zip() because tuple reuse nicely benefited the common case of for a,b,c in zip(alist, blist, clist): On another thread, I did see mention of

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: map doesn't use PyObject_CallFunctionObjArgs(). If compare results for map with results for filter and list.sort, seems that PyTuple_New() is responsible for 24% and PyObject_CallFunctionObjArgs() adds other 14%. -- priority: normal - low

[issue23507] Tuple creation is too slow

Antoine Pitrou added the comment: By the way, is PyTuple_New() really the culprit here? Or is it the valist handling in PyObject_CallFunctionObjArgs()? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Maybe we want a facility to create on-stack static-size tuples? There is no guarantee that called function doesn't save the reference to args. How many functions can benefit from this approach, though? From hand-writing caching? Any function, that

[issue23507] Tuple creation is too slow

Antoine Pitrou added the comment: How many functions can benefit from this approach, though? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507 ___

[issue23507] Tuple creation is too slow

Antoine Pitrou added the comment: Maybe we want a facility to create on-stack static-size tuples? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507 ___

[issue23507] Tuple creation is too slow

Raymond Hettinger added the comment: I had done something like this for zip() long ago and had gotten a nice speed boost. I remember looking at whether it should be applied elsewhere but don't remember why I decided against it. -- assignee: - rhettinger nosy: +rhettinger

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Fixed bugs found by Victor. Thank you Victor. Yes, zip() already uses similar approach. -- Added file: http://bugs.python.org/file38244/reuse_argtuples_2.patch ___ Python tracker rep...@bugs.python.org

[issue23507] Tuple creation is too slow

Serhiy Storchaka added the comment: Note the check for Py_REFCNT() == 1. Whithout it the code would be incorrect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507 ___

[issue23507] Tuple creation is too slow

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507 ___ ___

[issue23507] Tuple creation is too slow

Changes by Stefan Behnel sco...@users.sourceforge.net: -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23507 ___ ___