Quelques réponses réclamé un "10x" avantage de vitesse pour deque vs liste-utilisé-comme-FIFO lorsque les deux ont de 1000 entrées, mais c'est un peu un a surenchéri:
$ 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
est votre ami, vraiment utile et simple micro-analyse comparative de l'approche! Avec elle, vous pouvez bien sûr aussi trivialement explorer les performances dans bien des cas moins importants:
$ 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
(pas très différents de 12 au lieu de 100 éléments btw), et en plus-les plus grands:
$ 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
Vous pouvez voir que la revendication de O(1) performance pour deque est fondé, alors qu'une liste est plus de deux fois plus lent autour de 1 000 articles, un ordre de grandeur autour de 10 000. Vous pouvez également voir que, même dans de tels cas, vous êtes seulement de perdre 5 microsecondes par ajout/pop paire et de décider quelle est l'importance que le gaspillage est (si si c'est tout ce que vous faites avec ce conteneur deque a aucun inconvénient, de sorte que vous pourriez aussi bien basculer, même si 5 usec de plus ou de moins ne fera pas une grande différence).