jeremy wrote:
> FL> has anyone benchmarked the abstract sequence API? how much
> FL> slower is it? would it be a good idea to treat lists as a
> FL> special case, to avoid slowing down existing code?
>=20
> The abstract interface is fairly expensive. The current code uses
> PyList_GET_ITEM to access the elements of the list. The abstract
> interface adds two function calls (PySequence_GetItem,
> PyList_GetItem). The first function just does a couple of sanity
> checks (verify arg is sequence & that it has get_item). The second
> function verifies that the arg is a list, then does a bounds check.
> None of the work that either of these functions does is necessary for
> the list case!
just for the record, I just changed some generic sequence code
to something like:
if (PyList_Check(seq) || PyTuple_Check(seq))
Py_INCREF(seq);
else if (PySequence_Check(seq)) {
seq =3D PySequence_Tuple(seq);
if (!seq)
return NULL;
} else {
PyErr_SetString(PyExc_TypeError, "argument must be a sequence");
return NULL;
}
... allocate PyObject_Length(seq) slots ...
if (PyList_Check(seq))
... list code using PyList_GET_ITEM
else
... tuple code using PyTuple_GET_ITEM
Py_DECREF(seq);
for the standard case (lists, in this case), this resulted in a
total speedup of 4 times (this includes some other overhead).
so in other words, this construct is more than 4 times faster
than plain use of PySequence_GetItem.
guess it's time to fix a couple of things in PIL...
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4