Issue 36062: move index normalization from list_slice() to PyList_GetSlice() (original) (raw)

Issue36062

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

Messages (3)
msg336184 - (view)	Author: Sergey Fedoseev (sir-sigurd) *	Date: 2019-02-21 06:30
list_slice() is used by PyList_GetSlice(), list_subscript() and for list copying. In list_subscript() slice indices are already normalized with PySlice_AdjustIndices(), so slice normalization currently performed in list_slice() is only needed for PyList_GetSlice(). Moving this normalization from list_slice() to PyList_GetSlice() provides minor speed-up for list copying and slicing: $ python -m perf timeit -s "copy = [].copy" "copy()" --duplicate=1000 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 26.5 ns +- 0.5 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 25.7 ns +- 0.5 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 26.5 ns +- 0.5 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 25.7 ns +- 0.5 ns: 1.03x faster (-3%) $ python -m perf timeit -s "l = [1]" "l[:]" --duplicate=1000 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 71.5 ns +- 1.4 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 70.2 ns +- 0.9 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 71.5 ns +- 1.4 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 70.2 ns +- 0.9 ns: 1.02x faster (-2%)
msg336185 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2019-02-21 06:51
New changeset ef1b88bf57aae93893d55f1b9c9639dbe9cc7786 by Serhiy Storchaka (Sergey Fedoseev) in branch 'master': bpo-36062: Minor speed-up for list slicing and copying. (GH-11967) https://github.com/python/cpython/commit/ef1b88bf57aae93893d55f1b9c9639dbe9cc7786
msg336186 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2019-02-21 06:57
Nice! This is an example of good microoptimization. The performance gain is tiny (although measurable), but the cost is virtually zero: it does not increase code complexity and does not have side effects.