在实践中哪个更快：Treap 或 Splay 树？答案

【问题标题】：What is faster in practice: Treap or Splay tree?在实践中哪个更快：Treap 或 Splay 树？
【发布时间】：2018-01-06 21:17:53
【问题描述】：

我已经学会了 Treap 和 Splay tree 并且使用它们解决了一些问题。
理论上，它们的复杂度平均为 O(log n)，但在最坏的情况下 Treap 的复杂度为 O(n) 而 Splay 树的是摊销 O(log n)。

Treap 中最坏的情况发生在哪种情况下（因为它的优先级是随机选择的），并且 Treap 真的比 Splay 慢树？我已经使用 Splay tree 和 Treap 解决了 SPOJ 上的一些任务，使用 Treap 的解决方案要快一些（大约 0.2 s) 比使用 Splay 树 的。那么哪一个实际上更快，我应该主要使用哪一个以及何时使用？

【问题讨论】：

标签： algorithm computer-science splay-tree treap

【解决方案1】：

在实践中，两者都没有真正使用。 They are often way more complex than necessary. 他们在学术和编程竞赛中大多很有趣。我真的只在生产代码中遇到过红黑树和B树，其他类型的平衡树非常罕见。

如果您发现 treaps 更快，那么就使用它们，因为 O(n) 最坏情况下的时间性能是由于运气不好，而不是对抗性输入。展开树稍微慢一些，因为您必须在实践中为摊销“支付”费用才能将最坏的情况降低到 O(log n)。

【讨论】：

我不确定我是否购买了复杂性参数。我记得处理红黑树的情况让我的大脑受伤，而相比之下，张开的树则轻而易举。它们肯定更难使用，因为您失去了可预测的性能并且需要评估您的应用程序是否可以承受摊销损失（尽管在实践中我承认我已经知道使用向量等但没有给出太多。 )
我承认我只在 std::map 中看到过红黑树，显然选择在哈希映射上使用它们更多是为了历史一致性：stackoverflow.com/questions/5288320/… 我在实践中同意由于需要额外的复杂性，平衡树没有那么有用。我也只是使用向量。
根据我的经验（无论是在实践中还是在 ACM 风格的比赛中），trap 比 RB 树更容易编码（和记住）。除非你的 RNG 很烂（rand 和 MT19937，我在看着你），否则实际的代码也更简单更快。我能想到的比treaps更喜欢RB树的唯一原因是害怕随机算法......如果你记得std::sort是如何工作的，这可能是有道理的（快速排序，直到它检测到事情变得太慢，因为它有对抗性输入）。