how not use memmove when insert a object in the list

[kyo guan]

Hi :

python list object like a stl vector, if insert a object in the front or the middle of it,
all the object after the insert point need to move backward.

look at this code ( in python 2.4.3)

static int
ins1(PyListObject *self, int where, PyObject *v)
{
int i, n = self->ob_size;
PyObject **items;
if (v == NULL) {
PyErr_BadInternalCall();
return -1;
}
if (n == INT_MAX) {
PyErr_SetString(PyExc_OverflowError,
"cannot add more objects to list");
return -1;
}

if (list_resize(self, n+1) == -1)
return -1;

if (where < 0) {
where += n;
if (where < 0)
where = 0;
}
if (where > n)
where = n;
items = self->ob_item;
for (i = n; --i >= where; ) /// here, why not use memmove? it would be more speed then this loop.
items[i+1] = items;
Py_INCREF(v);
items[where] = v;
return 0;
}



Kyo.

 

[John Machin]

Hi :

python list object like a stl vector, if insert a object in the front or the middle of it,
all the object after the insert point need to move backward.

look at this code ( in python 2.4.3)

for (i = n; --i >= where; ) /// here, why not use memmove? it would be more speed then this loop.
items[i+1] = items;

Here's a guess, based on similar work on another language a few
reincarnations ago

memmove() is very general-purpose, and starts with byte addresses and a
byte count. For a small number of list elements, by the time that
memmove has determined (1) the move overlaps (2) both source and target
are on word boundaries and it is moving a whole number of words (3) what
direction (up or down), the DIY code has already finished. For a large
number of items, memmove *may* be faster (depending on the architecture
and the compiler) but you are using the wrong data structure anyway.