【问题标题】:Are there any benchmarks showing good performance of `collections.deque`?是否有任何基准显示 `collections.deque` 的良好性能?
【发布时间】:2011-07-18 21:21:12
【问题描述】:

我一直对 Python 的 collections.deque 对象很感兴趣。看起来像一个列表,只是在开头添加/删除项目比在列表中要快。

这让我想在我的代码中的各个地方用deque 替换list,在这些地方我有一个我留下的列表。所以我的问题是:在这种情况下,有没有人将dequelist 进行对比?

【问题讨论】:

  • 你为什么不自己做这样的基准并在这里报告呢?而是要求别人代表你自己做这些事情?谢谢
  • @eat 他是在询问是否有人已经执行了基准测试,而不是要求您这样做。
  • @eat:也许有人已经花了几个小时在各种不同的场景中对 deque 和 list 进行基准测试?如果我们都接触到这项研究而不是复制它,不是更好吗?
  • 您确实有自己的用例,其他人有他们的,而我们其他人也有许多不同的用例。所以基本上它应该更直接地利用你的而不是试图理解(适应)别人的。所以我的观点很简单,每个程序员都应该能够衡量他们代码的性能。只是不要根据一些通用基准采取行动,而是自己找出来。谢谢

标签: python data-structures collections complexity-theory deque


【解决方案1】:

我刚刚做了一个快速的谷歌搜索,找到了两个带有代码和数字的来源:

邮件列表帖子: http://coding.derkeiler.com/Archive/Python/comp.lang.python/2010-01/msg02138.html

一篇博文: http://txzone.net/2010/04/python-is-x-is-better-than-y-round-1-deque-vs-list/

对于大多数操作,列表看起来比双端队列稍快,但双端队列会破坏 .pop[0] 处的列表(对于 100,000 个元素列表来说是 2 个数量级)。

【讨论】:

  • 在迈克尔编辑之前,这是一个边界link-only answer。将来,请扩展您的答案以在此处包含尽可能多的信息,并使用链接仅供参考。
猜你喜欢
  • 1970-01-01
  • 2012-06-17
  • 2011-12-13
  • 1970-01-01
  • 1970-01-01
  • 2012-05-15
  • 2013-11-25
  • 2020-10-30
  • 2011-03-21
相关资源
最近更新 更多