Timing Difference: insert vs. append & reverse

[John Keeling]

Dear all,
I tried the test program below. My interest is to examine timing
differences between insert vs. append & reverse for a list. My results
on my XP Python 2.3.4 are as follows:
time_reverse 0.889999389648
time_insert 15.7750005722
Over multiple runs ... the time taken to insert at the head of a list,
vs. the time taken to append to a list and then reverse it is
typically 16 or 17 times longer.
I would have expected the insert operation to be faster than the
combined append & reverse operations. Is this behaviour surprising, or
is there a good reason why there is this large performance difference?
Thanks,
John

from time import time

def test():
time_reverse =0.0
time_insert =0.0

for lindx in xrange(100):
tmp1 =[]
time_reverse -=time()
for indx in xrange(10000):
tmp1.append(ind x)
tmp1.reverse()
time_reverse +=time()

tmp2 =[]
time_insert -=time()
for indx in xrange(10000):
tmp2.insert(0, indx)
time_insert +=time()
assert tmp1==tmp2
print "time_rever se ", time_reverse
print "time_inser t ", time_insert

test()

[Duncan Booth]

jo**********@ya hoo.com (John Keeling) wrote in
news:35******** *************** ***@posting.goo gle.com:

I tried the test program below. My interest is to examine timing
differences between insert vs. append & reverse for a list. My results
on my XP Python 2.3.4 are as follows:
time_reverse 0.889999389648
time_insert 15.7750005722
Over multiple runs ... the time taken to insert at the head of a list,
vs. the time taken to append to a list and then reverse it is
typically 16 or 17 times longer.
I would have expected the insert operation to be faster than the
combined append & reverse operations. Is this behaviour surprising, or
is there a good reason why there is this large performance difference?

A list is implemented by an array of pointers to the objects it contains.

Every time you call 'insert(0, indx)', all of the pointers already in the
list have to be moved up once position before the new one can be inserted
at the beginning.

When you call 'append(indx)' the pointers only have to be copied if there
isn't enough space in the currently allocated block for the new element. If
there is space then there is no need to copy the existing elements, just
put the new element on the end and update the length field. Whenever a new
block does have to be allocated that particular append will be no faster
than an insert, but some extra space will be allocated just in case you do
wish to extend the list further.

If you expected insert to be faster, perhaps you thought that Python used a
linked-list implementation. It doesn't do this, because in practice (for
most applications) a list based implementation gives better performance.

[Istvan Albert]

John Keeling wrote:

I tried the test program below. My interest is to examine timing
differences between insert vs. append & reverse for a list.

But what you are measuring is the difference between
one particular insert (where the index is 0) and the
combination of two other builtin operators that (in this
particular case) have the same effect.

While your observation makes a good point, in the end
we should pleased not surprised when we find ways to
speed up these specific cases.

Istvan.

[Duncan Smith]

"John Keeling" <jo**********@y ahoo.com> wrote in message
news:35******** *************** ***@posting.goo gle.com...

Dear all,
I tried the test program below. My interest is to examine timing
differences between insert vs. append & reverse for a list. My results
on my XP Python 2.3.4 are as follows:
time_reverse 0.889999389648
time_insert 15.7750005722
Over multiple runs ... the time taken to insert at the head of a list,
vs. the time taken to append to a list and then reverse it is
typically 16 or 17 times longer.

Shouldn't that really be insert vs. reverse & append & reverse. :-)

Duncan

[John Keeling]

Duncan,

A list is implemented by an array of pointers to the objects it contains. That explains it.
If you expected insert to be faster, perhaps you thought that Python used a
linked-list implementation. It doesn't do this,

Yes, that is how I was thinking. It is interesting to see how
functions may perform very differently from how we may initially
expect. I've also noted an approximate two time difference between
"del list[index] and list.pop(index) ". I know that they do different
things (the return value from pop), however in many places my code
uses pop and ignores the return value when it would be faster to use
del. I am making changes based on these observations now.
Thanks,
John

[John Keeling]

Duncan,

A list is implemented by an array of pointers to the objects it contains. That explains it.
If you expected insert to be faster, perhaps you thought that Python used a
linked-list implementation. It doesn't do this,

Yes, that is how I was thinking. It is interesting to see how
functions may perform very differently from how we may initially
expect. I've also noted an approximate two time difference between
"del list[index] and list.pop(index) ". I know that they do different
things (the return value from pop), however in many places my code
uses pop and ignores the return value when it would be faster to use
del. I am making changes based on these observations now.
Thanks,
John

[Terry Reedy]

"John Keeling" <jo**********@y ahoo.com> wrote in message
news:35******** *************** ***@posting.goo gle.com...

expect. I've also noted an approximate two time difference between
"del list[index] and list.pop(index) ".

Here is one way to get some insight into such things:

def ldel(lisp, index): .... del lisp[index]
.... def lpop(lisp, index): .... return lisp.pop(index)
.... import dis
dis.dis(ldel) 0 SET_LINENO 1

3 SET_LINENO 2
6 LOAD_FAST 0 (lisp)
9 LOAD_FAST 1 (index)
12 DELETE_SUBSCR
13 LOAD_CONST 0 (None)
16 RETURN_VALUE dis.dis(lpop)

0 SET_LINENO 1

3 SET_LINENO 2
6 LOAD_FAST 0 (lisp)
9 LOAD_ATTR 1 (pop)
12 LOAD_FAST 1 (index)
15 CALL_FUNCTION 1
18 RETURN_VALUE
19 LOAD_CONST 0 (None)
22 RETURN_VALUE

You can be pretty sure that the specific opcode DELETE_SUBSCR (ipt) is
faster than the generic CALL_FUNCTION, which will eventually call (I
presume) the same C code. (The extra attribute lookup and load take some
extra time too, but the call should be the main culprit).

Terry J. Reedy

[John Keeling]

It is so cool to be able to get the disassembly
so easily.... thanks v. much Terry.
Cheers,
John

import dis
dis.dis(ldel)

0 SET_LINENO 1

3 SET_LINENO 2
6 LOAD_FAST 0 (lisp)
9 LOAD_FAST 1 (index)
12 DELETE_SUBSCR
13 LOAD_CONST 0 (None)
16 RETURN_VALUE

[Bryan Olson]

Duncan Booth wrote:

A list is implemented by an array of pointers to the objects it contains.

Every time you call 'insert(0, indx)', all of the pointers already in the
list have to be moved up once position before the new one can be inserted
at the beginning.

When you call 'append(indx)' the pointers only have to be copied if there
isn't enough space in the currently allocated block for the new element. If
there is space then there is no need to copy the existing elements, just
put the new element on the end and update the length field. Whenever a new
block does have to be allocated that particular append will be no faster
than an insert, but some extra space will be allocated just in case you do
wish to extend the list further.

If you expected insert to be faster, perhaps you thought that Python used a
linked-list implementation. It doesn't do this, because in practice (for
most applications) a [array] based implementation gives better performance.

True, but an array implementation can easily support amortized
constant-time insert/delete at *either* end (without breaking
constant-time indexing). The same trick of keeping extra space
at the tail end can work at the head; it requires keeping one
additional offset to show where the occupied cells start.
--
--Bryan

[Terry Reedy]

"John Keeling" <jo**********@y ahoo.com> wrote in message
news:35******** *************** ***@posting.goo gle.com...

It is so cool to be able to get the disassembly
so easily.... thanks v. much Terry.

Since byte code is not (typically) written by hand, the symbolic names can
be long enough to be mostly self-explanatory, rather than short and crytic.
If any are not, for you, the Lib Manual dis module section has subsection
with all codes explained.

TJR