New submission from Antoine Pitrou <pit...@free.fr>: This is an experiment which turns out to yield little benefits, except on micro-benchmarks such as:
$ ./python -m timeit -s "a=[1,2,3]" "a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];" -> before: 1000000 loops, best of 3: 1.14 usec per loop -> after: 1000000 loops, best of 3: 0.759 usec per loop On IRC, Raymond pointed out that the long representation is not very friendly to direct manipulation for small ints, but even then it's not obvious it would benefit a lot: a large amount of time is certainly spent accessing the Python stack, manipulating reference counts, decoding opcodes and checking array bounds. The conclusion could be that such special-casing is futile when the body of code it avoids executing isn't big enough. Also, adding runtime checks has its own performance cost (more CPU instructions to execute, possible pipeline flushes due to branch misprediction, and pollution of branch prediction caches). ---------- components: Interpreter Core files: evalsubscr.patch keywords: patch messages: 115888 nosy: mark.dickinson, pitrou, rhettinger priority: low severity: normal status: open title: Fast path for small int-indexing of lists and tuples type: performance versions: Python 3.2 Added file: http://bugs.python.org/file18799/evalsubscr.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9800> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
