Issue 36031: add internal API function to effectively convert just created list to tuple (original) (raw)

Created on 2019-02-19 08:35 by sir-sigurd, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (5)
msg335901 - (view)	Author: Sergey Fedoseev (sir-sigurd) *	Date: 2019-02-19 08:35
There are several cases in CPython sources when PyList_AsTuple() is used with just created list and immediately after that this list is Py_DECREFed. This operation can be performed more effectively since refcount of items is not changed. For example it gives such speed-up for BUILD_TUPLE_UNPACK: Before: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 8.75 ms +- 0.10 ms After: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 5.41 ms +- 0.07 ms
msg335906 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2019-02-19 08:52
Could you provide more real world examples? Optimizing just one artificial example does not look impressive.
msg335917 - (view)	Author: Sergey Fedoseev (sir-sigurd) *	Date: 2019-02-19 10:04
Does this look like more real world example? Before: $ python -m perf timeit -s "t = (1, 2, 3)" "(*t, 4, 5)" ..................... Mean +- std dev: 95.7 ns +- 2.3 ns After: $ python -m perf timeit -s "t = (1, 2, 3)" "(*t, 4, 5)" ..................... Mean +- std dev: 85.1 ns +- 0.6 ns
msg336040 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2019-02-20 06:36
-1 This technique has a low payoff (possibly even zero due to memcpy() overhead) but is likely to create future maintenance issues (risk of bugs due to the fragility of assuming a refcnt of one, awkwardness of maintenance if we have to alter the surrounding code).
msg336063 - (view)	Author: STINNER Victor (vstinner) *	Date: 2019-02-20 10:48
_PyList_ConvertToTuple(PyObject *v): assert(Py_REFCNT(v) == 1); I don't think that _PyList_ConvertToTuple() usage is common enough to justify this micro-optimization. IMHO "Py_REFCNT(v) == 1" assumption is too strong. Python internals can be very surprising, especially when borrowered references and the garbage collector comes into the game. I concur with Serhiy and Raymond: it's too risky with very low benefit. It is likely to have no significant impact on macro benchmarks like https://pyperformance.readthedocs.io/ ( https://speed.python.org/ ).