Efficiency of using a Python list as a queue Efficiency of using a Python list as a queue python python

Efficiency of using a Python list as a queue


Some answers claimed a "10x" speed advantage for deque vs list-used-as-FIFO when both have 1000 entries, but that's a bit of an overbid:

$ python -mtimeit -s'q=range(1000)' 'q.append(23); q.pop(0)'1000000 loops, best of 3: 1.24 usec per loop$ python -mtimeit -s'import collections; q=collections.deque(range(1000))' 'q.append(23); q.popleft()'1000000 loops, best of 3: 0.573 usec per loop

python -mtimeit is your friend -- a really useful and simple micro-benchmarking approach! With it you can of course also trivially explore performance in much-smaller cases:

$ python -mtimeit -s'q=range(100)' 'q.append(23); q.pop(0)'1000000 loops, best of 3: 0.972 usec per loop$ python -mtimeit -s'import collections; q=collections.deque(range(100))' 'q.append(23); q.popleft()'1000000 loops, best of 3: 0.576 usec per loop

(not very different for 12 instead of 100 items btw), and in much-larger ones:

$ python -mtimeit -s'q=range(10000)' 'q.append(23); q.pop(0)'100000 loops, best of 3: 5.81 usec per loop$ python -mtimeit -s'import collections; q=collections.deque(range(10000))' 'q.append(23); q.popleft()'1000000 loops, best of 3: 0.574 usec per loop

You can see that the claim of O(1) performance for deque is well founded, while a list is over twice as slow around 1,000 items, an order of magnitude around 10,000. You can also see that even in such cases you're only wasting 5 microseconds or so per append/pop pair and decide how significant that wastage is (though if that's all you're doing with that container, deque has no downside, so you might as well switch even if 5 usec more or less won't make an important difference).


You won't run out of memory using the list implementation, but performance will be poor. From the docs:

Though list objects support similar operations, they are optimized for fast fixed-length operations and incur O(n) memory movement costs for pop(0) and insert(0, v) operations which change both the size and position of the underlying data representation.

So using a deque will be much faster.


From Beazley's Python Essential Reference, Fourth Edition, p. 194:

Some library modules provide new types that outperform the built-ins at certain tasks. For instance, collections.deque type provides similar functionality to a list but has been highly optimized for the insertion of items at both ends. A list, in contrast, is only efficient when appending items at the end. If you insert items at the front, all of the other elements need to be shifted in order to make room. The time required to do this grows as the list gets larger and larger. Just to give you an idea of the difference, here is a timing measurement of inserting one million items at the front of a list and a deque:

And there follows this code sample:

>>> from timeit import timeit>>> timeit('s.appendleft(37)', 'import collections; s = collections.deque()', number=1000000)0.13162776274638258>>> timeit('s.insert(0,37)', 's = []', number=1000000)932.07849908298408

Timings are from my machine.


2012-07-01 Update

>>> from timeit import timeit>>> n = 1024 * 1024>>> while n > 1:...     print '-' * 30, n...     timeit('s.appendleft(37)', 'import collections; s = collections.deque()', number=n)...     timeit('s.insert(0,37)', 's = []', number=n)...     n >>= 1... ------------------------------ 10485760.1239769458770752799.2552740573883------------------------------ 5242880.06924104690551758148.9747350215912------------------------------ 2621440.02917098999023437535.077512979507446------------------------------ 1310720.0137379169464111339.134140014648438------------------------------ 655360.0067110061645507811.8818109035491943------------------------------ 327680.003273010253906250.48307204246520996------------------------------ 163840.00163888931274414060.11021995544433594------------------------------ 81920.00082492828369140620.028419017791748047------------------------------ 40960.000449180603027343750.00740504264831543------------------------------ 20480.000211954116821289060.0021741390228271484------------------------------ 10240.000112056732177734380.0006101131439208984------------------------------ 5126.198883056640625e-050.00021386146545410156------------------------------ 2562.9087066650390625e-058.797645568847656e-05------------------------------ 1281.5974044799804688e-053.600120544433594e-05------------------------------ 648.821487426757812e-061.9073486328125e-05------------------------------ 325.0067901611328125e-061.0013580322265625e-05------------------------------ 163.0994415283203125e-065.9604644775390625e-06------------------------------ 83.0994415283203125e-065.0067901611328125e-06------------------------------ 43.0994415283203125e-064.0531158447265625e-06------------------------------ 22.1457672119140625e-062.86102294921875e-06