在red-black tree上插入的最坏情况运行时间为O(lg n)，如果我在树上执行in-order walk，我基本上会访问每个节点，因此总的最坏情况运行时打印已排序的集合将是O（n lg n）
我很好奇，为什么red-black trees不适合排序quick sort（平均案例运行时间为O(n lg n)。
我看到这可能是因为red-black trees没有就地排序，但我不确定，所以也许有人可以提供帮助。
答案 0 :(得分：8)
了解哪种排序算法的效果更好取决于您的数据和情况。
如果您正在谈论一般/实际术语，
Quicksort（您随机选择枢轴/只选择一个固定的，最坏情况Omega（n ^ 2））可能比红黑树更好，因为（不一定按重要性排序）
Quicksort就位。保持低内存。假设这个quicksort例程是处理大量数据的程序的一部分。如果您继续使用大量内存，您的操作系统可能会开始交换您的进程内存并丢弃您的性能。
Quicksort内存访问已本地化。这适用于缓存/交换。
Quicksort可以很容易地并行化（这些天可能更相关）。
如果你试图通过使用数组来优化二叉树排序（使用二进制树而不平衡），你最终会做像Quicksort这样的事情！
红黑树有内存开销。您可能需要多次分配节点，使用树的内存需求是使用数组的两倍/三倍。
排序后，假设您想要第1045个（比较）元素，您需要在树中维护订单统计信息（因此会产生额外的内存成本），并且您将拥有O（logn）访问时间！
红黑树只有访问下一个元素的开销（指针查找）
红黑树与缓存不兼容，指针访问可能会导致更多交换。
红黑树的旋转会增加O（nlogn）中的常数因子。
也许是最重要的原因（但如果你有可用的lib等无效），Quicksort很容易理解和实现。即使是小学生也能理解它！
我会说你试着测量两种实现，看看会发生什么！
另外，Bob Sedgewick做了一个关于quicksort的论文！可能值得一读。
答案 1 :(得分：2)
有很多排序算法是最差的O(n log n) - 例如，合并排序。 Quicksort首选的原因是因为它在实践中更快，即使在算法上它可能不如其他算法那么好。
通常内置排序使用各种方法的组合，具体取决于n。
的值答案 2 :(得分：1)
在许多情况下，红背树的排序并不错。我的测试显示，与自然合并排序相比，红黑树在以下地方表现优异：
树木更适合Dups： 所有需要重复的重复测试，树算法更好。这并不令人惊讶，因为树从一开始就可以保持很小，因此为内联数组排序设计的算法可能会在更长的时间内传递更大的段。
树更适合随机： 所有使用随机，树算法的测试都更好。这也不令人惊讶，因为在树中，元素之间的距离较短并且不需要移位。因此，重复插入树可能比排序数组需要更少的工作量。
因此我们得到的印象是，自然合并排序仅在升序和降序特殊情况下表现优异。甚至不能说快速排序。
了解测试用例here。
P.S。：应该注意的是，使用树进行分类是非常重要的。人们不仅要提供插入例程，还要提供一个可以将树线性化回数组的例程。我们目前正在使用get_last和一个前驱例程，它不需要堆栈。但是这些例程不是O（1），因为它们包含循环。
答案 3 :(得分：0)
大O时间复杂度度量通常不考虑标量因子，例如，O（2n）和O（4n）通常仅减少为O（n）。时间复杂度分析基于算法级别的操作步骤，而不是严格的编程级别，即没有源代码或本机机器指令考虑因素。
Quicksort通常比基于树的排序更快，因为（1）方法具有相同的算法平均时间复杂度，以及（2）查找和交换操作在使用简单数组时比使用红色时需要更少的程序命令和数据访问黑树，即使树使用基于数组的底层实现。维护红黑树约束需要额外的操作步骤，数据字段值存储/访问（节点颜色）等，而不是快速排序的简单数组分区交换步骤。
最终结果是红黑树的标量系数高于标准O（n log n）平均时间复杂度分析结果所模糊的快速排序。
简要讨论了与机器架构相关的其他一些实际考虑因素答案 4 :(得分：0)
通常，O（nlgn）算法的表示可以扩展到A * nlgn + B，其中A和B是常数。有许多算法证明表明快速排序的系数小于其他算法的系数。这是最好的情况（快速排序对排序数据执行可怕）。
答案 5 :(得分：0)
在我看来，解释所有排序程序之间差异的最佳方法是。 （我的答案是那些在实践中快速排序比另一种排序算法更快的人。）
“认为你是在一台非常慢的电脑上运行”。
“我正在利用时间让人们了解时间的重要性。”
现在，从所有排序操作中，快速排序的比较非常少，而且元素的交换非常少。
由于这个主要原因，快速排序速度更快。