[New-bugs-announce] [issue9800] Fast path for small int-indexing of lists and tuples

[Antoine Pitrou]

New submission from Antoine Pitrou <pitrou at 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 <report at bugs.python.org>
<http://bugs.python.org/issue9800>
_______________________________________