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