[Python-Dev] tuple[int] optimization (original) (raw)

Ryan Kelly ryan at rfk.id.au
Sun Jul 24 01:13:07 CEST 2011

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 BINARYSUBSCR operation. ceval.c has optimization for list: case BINARYSUBSCR: w = POP(); v = TOP(); if (PyListCheckExact(v) && PyIntCheckExact(w)) { /* INLINE: list[int] */ Pyssizet i = PyIntAsSsizet(w); if (i < 0)_ _i += PyListGETSIZE(v);_ _if (i >= 0 && i < PyListGETSIZE(v)) { x = PyListGETITEM(v, i); PyINCREF(x); } else goto slowget; } else slowget: x = PyObjectGetItem(v, w); PyDECREF(v); PyDECREF(w); SETTOP(x); if (x != NULL) continue; break; For tuple code follows slow way via tpasmapping 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 BINARYSUBSCR?

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>

More information about the Python-Dev mailing list