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).

For what it's worth, a similar fast path existed in Python 2 for lists (but not tuples).  It was removed for Python 3.  I'm not sure why it was removed, but it may have been part of removing the PyInt type.

A disadvantage of the patch is that ceval.c needs to know about the internal implementation of a PyLong.  At the moment, this information is encapsulated only in Objects/longobject.c and a couple of other places (I think marshal.c).

In the past, we've allow ceval.c to peer through encapsulation in order to have fast paths.

As I mentioned, the speedup is invisible anyway, so it's not really a "fast path" ;)

At any rate, I believe this used to be a fast-path.  IIRC, Aahz put it in after demonstrating a considerable speed boost for common cases.  Aahz, do you have any institutional memory around this one?

Wasn't me!  And I've spent too little time on python-dev lately to
remember stuff like this.  :-(

I did some spelunking.  Guido committed the similar optimization in r8306.    The diff is at:
http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306

His commit message was:

    Huge speedup by inlining some common integer operations:
    int+int, int-int, int <compareop> int, and list[int].
    (Unfortunately, int*int is way too much code to inline.)

    Also corrected a NULL that should have been a zero.

It's possible that these kinds of optimizations were worthwhile with PyInt but aren't worthwhile with PyLong.

They were taken out by MvL in r59334, with a commit message of:

    Remove special-casing of integer operations, to stop
    using PyInt_CheckExact.

> I did some spelunking.  Guido committed the similar optimization in r8306.    The diff is at:
> http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306
> 
> His commit message was:
> 
>     Huge speedup by inlining some common integer operations:
>     int+int, int-int, int <compareop> int, and list[int].
>     (Unfortunately, int*int is way too much code to inline.)
> 
>     Also corrected a NULL that should have been a zero.
> 
> It's possible that these kinds of optimizations were worthwhile with
> PyInt but aren't worthwhile with PyLong.

It also doesn't say the individual contribution of each optimization,
and it also doesn't say on which kind of workloads the "huge speedup"
was witnessed (I would say that pystone is a possibility, or perhaps
even some timeit micro-benchmark).

I think the approach in issue10044 is better.

Closing this old pending issue due to lack of activity.