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
[email protected] | http://www.rfk.id.au/ramblings/gpg/ for details
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
