python - Bisect/Insort 的列表和双端队列的时间复杂度是否不同？

Question

据我所知，Python中的list是用数组实现的，而deque是用双链表实现的。在任何一种情况下，对某个值的二进制搜索都需要 O(logn) 时间，但是如果我们插入到该位置，则数组需要 O(n)，而双链表需要 O(1)。

那么，我们是否可以使用bisect、insort和deque的组合来实现时间复杂度与TreeMap相当的所有动态集合操作在 Java 中？

---

更新:我在这个 Leetcode 问题中测试了它:https://leetcode.com/problems/time-based-key-value-store/submissions/

完全出乎我的意料，当我从list切换到deque时，速度慢了很多。

Answer 1

对于您的标题问题:是的，他们有。

对于您假设的排序集实现问题:不，您不能。

第一，你在deque的实现上搞错了；它不是一个普通的“每个节点的项目”链接列表，它是每个节点的 block 项目(CPython 引用解释器上为 64，尽管这是一个实现细节)。除了头部和尾部 block 之外，内部 block 永远不会留空，因此在 deque 中途插入并不是特别便宜，它仍然需要移动一堆东西。它不像中间 list 插入那样 O(n)，因为它利用旋转的一些效率来旋转，附加到一侧或另一侧，然后旋转回来，但它与在链表中的已知点插入相去甚远，剩余 O(n) (尽管由于改组整个 block 比移动每个单独的项目更便宜，所以有很大的常数除数) .

第二，deque 中的每次查找都是O(n)，而不是像list O(1);如前所述，它有一个 64 的常数除数，并且它在 deque 两端附近下降到 O(1)，但它仍然是 O(n) 一般而言，它对于大型 deque 的扩展性很差。 bisect 搜索是 O(log n) 假设索引序列是 O(1)；对于 deque，它们将是 O(n log n)，因为它们会执行 log n O(n) 索引操作。这与您的测试结果相符； bisect+deque 明显更差。

Java 的 TreeMap 无论如何都不是根据二进制搜索和链表实现的；链表对此没有好处，因为最终一个完整的二分搜索必须来回遍历足够多的时间来完成 O(n) 的总工作，即使它只需要与 O( log n) 元素。 TreeMap 需要某种树结构，您不能只用链表和好的算法来伪造它。

内置替代品包括:

1. insort 一个普通的 list:当然它总体上是 O(n)，但是昂贵的部分(找到插入的地方)是 O(log n)，而且只有“腾出空间”的步骤是 O(n)，而且真的很便宜 O (n)(基本上是一个 memcpy)。对于真正庞大的 list 来说是 Not Acceptable ，但是您会惊讶于在开销明显超过 Python 的缓慢之前您需要多大的 list。
2. 延迟缓冲排序:如果查找不频繁，但插入很常见，则将排序推迟到需要时，以尽量减少排序操作的次数；只需将新元素附加到末尾而不进行排序并设置“需要排序”标志，并在设置标志后在查找之前重新排序。当输入已经大部分排序时，TimSort 算法非常做得很好(比不优化部分排序的通用排序通常更接近 O(n))，所以可能没问题。
3. 如果您在任何给定时间只需要最小的元素，heapq 模块可以使用真正的 O(log n) 插入和移除来做到这一点，并获得最小值使用 O(1)(它始终是索引 0)。
4. 使用sqlite3 数据库(可能通过shelve)，适当索引； sqlite3 索引默认使用 B 树，这意味着使用索引键排序的查询“免费”按排序顺序返回结果。

否则，您将不得不安装第三方模块，以提供正确排序的 set-like 类型。