STINNER Victor added the comment: > As noted above, it not reasonable for a C-API that isn't used internally > because there is no reasonable way to measure the effect without writing a C > extension.
Come on, there is a lot of C functions in Python using the C PyList_xxx() API. It's easy to write a benchmark on it in pure Python. Example. Without the patch (best of 10 runs): $ for i in $(seq 1 10); do ./python -m timeit -s 's="a " * 10**5' 's.split()'; done 1000 loops, best of 3: 1.40 msec per loop With the patch (best of 10 runs): $ for i in $(seq 1 10); do ./python -m timeit -s 's="a " * 10**5' 's.split()'; done 1000 loops, best of 3: 1.49 msec per loop It looks like list_check_fastpath2.diff makes PyList_Append() *slower* (6%) in practice. I expected it to be *faster*. Please try to reproduce my microbenchmark, timeit is not really reliable, and I hate microbenchmarks, it's easy to make mistakes :-/ Note: It looks like s.split() creates a list of 'a' strings where all 'a' strings are the same singleton. So I don't think that creating substrings has an important cost. > If you're going to be in the optimization business, I really wish you would > read some of the basics in the field so that each and every technique doesn't > have to be re-proved to you each time it used. It's easy to convince me: show me a benchmark where your patch makes the code faster :-) I don't think that there is a strict rule for a miniumum speedup in CPython. I'm open for discussion :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26201> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
