[Python-Dev] tuple[int] optimization

[Ryan Kelly]

On Sun, 2011-07-24 at 01:20 +0300, Andrew Svetlov wrote:
> tuple[int] is 30% slower than list[int].
> Please let me explain the problem.
> 
> (1, 2, 3)[1] has compiled as BINARY_SUBSCR operation.
> ceval.c has optimization for list:
> 
>         case BINARY_SUBSCR:
>             w = POP();
>             v = TOP();
>             if (PyList_CheckExact(v) && PyInt_CheckExact(w)) {
>                 /* INLINE: list[int] */
>                 Py_ssize_t i = PyInt_AsSsize_t(w);
>                 if (i < 0)
>                     i += PyList_GET_SIZE(v);
>                 if (i >= 0 && i < PyList_GET_SIZE(v)) {
>                     x = PyList_GET_ITEM(v, i);
>                     Py_INCREF(x);
>                 }
>                 else
>                     goto slow_get;
>             }
>             else
>               slow_get:
>                 x = PyObject_GetItem(v, w);
>             Py_DECREF(v);
>             Py_DECREF(w);
>             SET_TOP(x);
>             if (x != NULL) continue;
>             break;
> 
> For tuple code follows slow way via tp_as_mapping slot and calls
> tuplesubscript from Objects/tupleobject.c
> 
> Looks like tuple is goot applicant to be optimized as list does.
> tuples is used in python programs very often and getting element from
> tuple by index as common operation as list[int].
> 
> Is there reasons to prevent special case for tuples in BINARY_SUBSCR?

In latest trunk this optimisation seems to have gone away, the code is
now:

        TARGET(BINARY_SUBSCR)
            w = POP();
            v = TOP();
            x = PyObject_GetItem(v, w);
            Py_DECREF(v);
            Py_DECREF(w);
            SET_TOP(x);
            if (x != NULL) DISPATCH();
            break;

The implementation of PyObject_GetItem doesn't appear to have changed
though.  Maybe this optimisation was no longer worth it in practice? 


  Ryan



-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ryan at rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/ for details

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110724/6815fe62/attachment.pgp>