62

In python docs I can see that deque is a special collection highly optimized for poping/adding items from left or right sides. E.g. documentation says:

Deques are a generalization of stacks and queues (the name is pronounced “deck” and is short for “double-ended queue”). Deques support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction.

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.

I decided to make some comparisons using ipython. Could anyone explain me what I did wrong here:

In [31]: %timeit range(1, 10000).pop(0)
 10000 loops, best of 3: 114 us per loop

In [32]: %timeit deque(xrange(1, 10000)).pop() 
10000 loops, best of 3: 181 us per loop

In [33]: %timeit deque(range(1, 10000)).pop()
1000 loops, best of 3: 243 us per loop
Raymond Hettinger
  • 182,864
  • 54
  • 321
  • 419
Oleg Tarasenko
  • 8,244
  • 17
  • 64
  • 97
  • 3
    It takes O(n) time to create a `deque` object from a list (such as `range` or `xrange`). – Jayanth Koushik May 06 '14 at 06:25
  • What do you mean by "wrong"? What did you expect to happen? – freakish May 06 '14 at 06:26
  • 2
    Agree with @JayanthKoushik, time `.pop` after both list and deque created. – vaultah May 06 '14 at 06:26
  • 3
    deque has internal locks to achieve **thread safe**, but list doesn't. – Xing Fei May 06 '14 at 06:30
  • 1
    @XingFei No, collections.deque doesn't have internal locks. For that you want Queue.Queue. But the append(), appendleft(), pop(), popleft() and len() methods of deque can be considered atomic not by guarantee of contract, but by how they're implemented in CPython. See https://bugs.python.org/issue15329#msg199368 (For example, iterating over a deque is not thread-safe). – Jostikas Nov 07 '16 at 20:01

4 Answers4

114

Could anyone explain me what I did wrong here

Yes, your timing is dominated by the time to create the list or deque. The time to do the pop is insignificant in comparison.

Instead you should isolate the thing you're trying to test (the pop speed) from the setup time:

In [1]: from collections import deque

In [2]: s = list(range(1000))

In [3]: d = deque(s)

In [4]: s_append, s_pop = s.append, s.pop

In [5]: d_append, d_pop = d.append, d.pop

In [6]: %timeit s_pop(); s_append(None)
10000000 loops, best of 3: 115 ns per loop

In [7]: %timeit d_pop(); d_append(None)
10000000 loops, best of 3: 70.5 ns per loop

That said, the real differences between deques and list in terms of performance are:

  • Deques have O(1) speed for appendleft() and popleft() while lists have O(n) performance for insert(0, value) and pop(0).

  • List append performance is hit and miss because it uses realloc() under the hood. As a result, it tends to have over-optimistic timings in simple code (because the realloc doesn't have to move data) and really slow timings in real code (because fragmentation forces realloc to move all the data). In contrast, deque append performance is consistent because it never reallocs and never moves data.

Raymond Hettinger
  • 182,864
  • 54
  • 321
  • 419
  • 1
    Is deque implemented as a linked list? Or how can you guarantee it won't require realloc? – user3207838 Jan 03 '17 at 17:39
  • 18
    Yes, it uses linked list logic. More specifically, it uses a doubly-linked list of fixed length blocks. – Raymond Hettinger Jan 04 '17 at 07:00
  • 2
    Use of `realloc()` for lists is just an optimization. The list is over-allocated each time it is resized to guarantee O(1) amortized append performance, even if the data has to be copied on each resize. – augurar Feb 03 '17 at 06:45
  • 3
    @augurar The use of *realloc()* isn't an optimization, it is at the core of how lists grow. It is the overallocation strategy that is the optimization -- that strategy reduces the number of calls to *realloc()* but it does not eliminate them. *realloc()* is still called periodically. This makes timings less repeatable and harder to interpret because the realloc performance varies wildly depending on whether the data has to be copied. – Raymond Hettinger Nov 21 '18 at 09:02
  • @RaymondHettinger The algorithm used in [dynamic arrays](https://en.wikipedia.org/wiki/Dynamic_array) does not depend on the existence of the `realloc()` Unix syscall, it's just a practical optimization to avoid copying when possible. Even if the data has to be copied every time the array is resized, the algorithm still achieves [amortized](https://en.wikipedia.org/wiki/Amortized_analysis) `O(1)` insertion performance. – augurar Nov 22 '18 at 01:58
  • 3
    @augurar You're missing the point completely. Yes, there is amortized O(1) performance. However, the constant factor varies wildly because the underlying operation is sometimes cheap and sometimes expensive. – Raymond Hettinger Nov 23 '18 at 06:47
  • @RaymondHettinger do you mean `s = list(range(1000))` as `'range' object has no attribute 'append'`? – zyxue Feb 12 '20 at 17:45
  • 2
    @zyxue I'll update the answer. It was correct for Python 2 where *range()* returned a list. – Raymond Hettinger Feb 13 '20 at 04:05
38

For what it is worth:

python3

deque.pop vs list.pop

>  python3 -mtimeit -s 'import collections' -s 'items = range(10000000); base = [*items]' -s 'c = collections.deque(base)' 'c.pop()'
5000000 loops, best of 5: 46.5 nsec per loop 
    
> python3 -mtimeit -s 'import collections' -s 'items = range(10000000); base = [*items]' 'base.pop()'
5000000 loops, best of 5: 55.1 nsec per loop

deque.appendleft vs list.append

> python3 -mtimeit -s 'import collections' -s 'c = collections.deque()' 'c.appendleft(1)'
5000000 loops, best of 5: 52.1 nsec per loop

> python3 -mtimeit -s 'c = []' 'c.insert(0, 1)'
50000 loops, best of 5: 12.1 usec per loop

python2

> python -mtimeit -s 'import collections' -s 'c = collections.deque(xrange(1, 100000000))' 'c.pop()'
10000000 loops, best of 3: 0.11 usec per loop

> python -mtimeit -s 'c = range(1, 100000000)' 'c.pop()'
10000000 loops, best of 3: 0.174 usec per loop

> python -mtimeit -s 'import collections' -s 'c = collections.deque()' 'c.appendleft(1)'
10000000 loops, best of 3: 0.116 usec per loop

> python -mtimeit -s 'c = []' 'c.insert(0, 1)'
100000 loops, best of 3: 36.4 usec per loop

As you can see, where it really shines is in appendleft vs insert.

sberry
  • 113,858
  • 17
  • 127
  • 157
7

I found my way to this question and thought I'd offer up an example with a little context.
A classic use-case for using a Deque might be rotating/shifting elements in a collection because (as others have mentioned), you get very good (O(1)) complexity for push/pop operations on both ends because these operations are just moving references around as opposed to a list which has to physically move objects around in memory.

So here are 2 very similar-looking implementations of a rotate-left function:

def rotate_with_list(items, n):
    l = list(items)
    for _ in range(n):
        l.append(l.pop(0))
    return l

from collections import deque
def rotate_with_deque(items, n):
    d = deque(items)
    for _ in range(n):
        d.append(d.popleft())
    return d

Note: This is such a common use of a deque that the deque has a built-in rotate method, but I'm doing it manually here for the sake of visual comparison.

Now let's %timeit.

In [1]: def rotate_with_list(items, n):
   ...:     l = list(items)
   ...:     for _ in range(n):
   ...:         l.append(l.pop(0))
   ...:     return l
   ...: 
   ...: from collections import deque
   ...: def rotate_with_deque(items, n):
   ...:     d = deque(items)
   ...:     for _ in range(n):
   ...:         d.append(d.popleft())
   ...:     return d
   ...: 

In [2]: items = range(100000)

In [3]: %timeit rotate_with_list(items, 800)
100 loops, best of 3: 17.8 ms per loop

In [4]: %timeit rotate_with_deque(items, 800)
The slowest run took 5.89 times longer than the fastest. This could mean that an intermediate result is being cached.
1000 loops, best of 3: 527 µs per loop

In [5]: %timeit rotate_with_list(items, 8000)
10 loops, best of 3: 174 ms per loop

In [6]: %timeit rotate_with_deque(items, 8000)
The slowest run took 8.99 times longer than the fastest. This could mean that an intermediate result is being cached.
1000 loops, best of 3: 1.1 ms per loop

In [7]: more_items = range(10000000)

In [8]: %timeit rotate_with_list(more_items, 800)
1 loop, best of 3: 4.59 s per loop

In [9]: %timeit rotate_with_deque(more_items, 800)
10 loops, best of 3: 109 ms per loop

Pretty interesting how both data structures expose an eerily similar interface but have drastically different performance :)

ccchoy
  • 106
  • 2
  • 3
5

I would recommend you to refer https://wiki.python.org/moin/TimeComplexity

Python lists and deque have simlilar complexities for most operations(push,pop etc.)

  • 8
    But critically, *not* for `popleft` / `.pop(0)` / pop intermediate which is what this question was *trying* to measure. – Peter Cordes Oct 06 '19 at 19:46