在生产中你会在哪里使用splay-tree。我的意思是 REAL LIFE 示例。
我正在考虑使用try和splay树实现自动完成功能。对于大型数据集，通过trie从节点x遍历到叶子以返回结果不是一个好主意，因此想法是在trie中的节点内部有一个splay树，所以当用户输入'sta'时它将转到sta ，'a' - 节点然后返回splay树中的前5个元素（通过BFS /级别遍历，这不一定会改变/修改树）
当然，在选择自动完成变体之后，我们应该遍历trie并更新这些节点内的所有splay树。
由于splay树在并发环境中很敏感，因此我质疑它在生产中的用法
你的想法？
答案 0 :(得分：2)
对于很少或从未改变的数据，Splay树不是很好的匹配，特别是在线程环境中。读取操作期间的额外突变会破坏内存缓存，并可能产生不必要的锁争用。在任何情况下，对于只读数据结构，您可以对最佳树进行一次性计算。即使计算速度很慢，也不会对长期执行时间产生影响。
我并不完全相信大尝试是缓慢的，并且当然不是自动完成的情况。即使是不那么现代的硬件，与用户键入字符所花费的时间相比，trie遍历的成本是微不足道的，甚至是底层键盘驱动程序和输入处理器将按键传递到你的申请。
如果你真的需要优化特里结构，那么有充分的理由相信，一旦备选方案适合高速缓存行，具有根管道的混合数据结构与线性（或二进制）搜索相结合。这样可以最大限度地发挥trie大型扇出的优势，同时避免在线路末端存在较差的缓存行为和过多的存储开销。
对于经常修改的数据结构，Splay树最有用（如果它们对它们有用）。 ckassic示例是一个“rope”数据结构（字符串段的树），这是尝试通过避免大字符串副本来优化文本编辑器的一种方法。与诸如RB树之类的确定性树平衡算法相比，展开树算法具有简单的优点，并且仅触摸形成树遍历的一部分的节点。
然而，自平衡树库（许多现代编程语言的标准库的一部分）的现成可用性与经常令人失望的实验结果相结合，使得splay算法充其量只是一个利基产品，尽管它当然是一个引人入胜的想法
答案 1 :(得分：0)
我在网络负载优化中发现了一个非常有趣的 splay 树用法，它被称为 SplayNet。一个自治系统（我认为在 Facebook 下）可能在 2015 年左右实现了这一点，他们以某种方式设法将其内部通信负载降低了约 40%（？）。 所以Splaytrees 有一个很好的用法！
几周前，我还阅读了有关 Splaytrees 根据搜索序列中的传播而有用的文章。如果没有，您也可以使用 f.a.二叉树或一些静态树。但现在有一个，Splaytrees 表现更好（如果你使用无限时间）。
在我的论文中，我使用张开树作为实际搜索的预处理数据集合。所以 splay 树只存储最常见的搜索请求的结果。在下一步中，搜索从给定节点的展开树开始......我认为这对大数据集很有用，特别是如果它存储在不同的计算机/存储上，因此您的程序可以更好地猜测从哪里开始。 简单地说 - 我的 splaytrees 存储了给定数据结构/数据集的常见问题:)