链表相对二叉树的优势？

Posted 2023-02-25

【中文标题】链表相对二叉树的优势？

【英文标题】：Advantages of linked lists over binary trees?

【发布时间】：2011-01-03 10:08:08

【问题描述】：

标题大部分是不言自明的：链表相对于二叉树的优势是什么？我能想到的唯一一种链表更有效的情况是迭代每个元素，在这种情况下它仍然非常接近。看起来二叉树在访问数据和插入新元素方面都更快。那么为什么要使用链表呢？

【问题讨论】：

二叉树相对于 17 叉树的优势是什么？如果 2 比 1 好，那么 17 比 2 好很多，对吧？ :-)

@Ken：只要你能在一次操作中进行 17 次比较。

除了已经提到的所有内容之外，链表对于实现其他数据结构非常有用，例如堆栈和队列。

苹果比橙子有什么优势？

starblue：缺少单个切片使得中缀消耗 O(1) 而不是 O(n)，而且可食用的果皮也倾向于降低常数因子。

【参考方案1】：

如果存储了链表的尾部，那么插入链表肯定比插入二叉树快。如果不平衡，插入二叉树在最坏情况下是 O(N)（最好是 O(log N)）。如果它是平衡的，那么插入是 O(log N)，但是要保持它的平衡涉及到内务处理。如果保留尾部，则插入链表是 O(1)。

此外，正如 BillyONeal mentioned，二叉树通常是关联结构，而链表则不是。

【讨论】：

对于二叉 搜索 树来说是这样，但在更一般的（未排序的）二叉树的情况下，插入仍然是 O(1)——链表是，毕竟只是一棵退化的二叉树。

@Ken：如果不应用 some 的排序概念，那么一棵树就毫无用处。这可能不是词法顺序，而是一些索引。在任何情况下，都必须遵循一条路径来找到添加新值的正确节点，这仍然意味着最好的情况是 O(log N)，最坏的情况是 O(N)。 O(1) 插入仅适用于添加项目的节点不重要的情况，但在这种情况下，查找是 O(N)，并且根本没有数据组织，因此树的开销没有任何好处。

@P 爸爸，在谈到链表时，插入是一个令人困惑的术语。追加是 O(1) 操作，插入是 O(n)。

P Daddy：我的编译器在这里构建了一个 AST。那是一棵不按任何键排序的树，但仍然非常有用。 :-)

由于“排序”的定义是“按顺序排列”，我认为是的，它是，但这是一个毫无意义的语义论点。关键是，给定一个基态，必须遍历一棵树以找到添加新项目的适当位置。它必须有一些“沿着这条路到达这个节点”的概念。这是树木及其整个存在理由的唯一好处。没有顺序概念的树是没有意义的。

【参考方案2】：

与二叉树相比，从链表中删除项目更容易/更快，二叉树可能需要很少的操作来修复树。

【参考方案3】：

链表通常不用作关联容器（阅读：不用作字典）——仅用作项目的文字列表，如数组。当需要这种简单的数据结构时，二叉树的性能很差。

【参考方案4】：

在链表中，对象是由容器本身排序的，所以不需要对象的比较函数。

【参考方案5】：

一个公平的问题。我喜欢使用最“紧密”符合我需求的容器。例如，当您只需要一个没有实际后果的队列时，您可以使用列表......但是......队列针对这一特定任务进行了高度优化，即从前面弹出并在后面插入，没有额外的指针，或任何东西。通过使用最合适的类，即使它具有相同的 Big-O，您也可以确保不会得到任何额外的绒毛。有时那些隐藏的常量确实很重要。

【参考方案6】：

这主要取决于场景。如果保持链表的尾部，则在链表中插入速度很快。链表中的删除速度非常快，但如果在树中搜索它会更好（o(log(n) 表示高度平衡树），而 o(n) 在链表中。

【参考方案7】：

我假设您谈论的是实际的二叉搜索树，其中使用算法添加节点以最大化检索性能。与每个节点最多有 2 个子节点的简单树不同。

链表通常是未排序的，因此添加新节点只是一个 O(1) 操作，通常通过附加到链表的尾部。

另一方面，二叉树必须以特定的排序机制存储节点（并可能强制平衡）以提供更有效的搜索/检索操作。

如果您的算法不需要非常高效地检索项目，同时还提供项目的有效排序，那么链表可能就是您所需要的。

队列和堆栈是可以使用链表轻松实现的数据结构示例。

注意：插入链表是一种不同于基本添加/追加的操作（较慢）。插入通常需要沿着列表遍历，直到找到正确的位置，O(n)，其中 n 是列表长度。追加只是简单地添加到列表的尾部（因此 O(1)）