为什么实践中quicksort比其他排序算法更好？

^{这是Janoma对cs.SE的一个问题的转贴。对他或CS SE的全部荣誉和破坏。}

在标准算法课程中，我们学会了快速排序平均为O（n log n），在最坏情况下为O（n²）。同时，还研究了其他排序算法，它们在最坏的情况下为O（n log n）（例如mergesort和heapsort），在最坏的情况下甚至是线性时间（例如bubbleort），但还有一些额外的内存需求。

快速浏览一下更多的运行时间后，自然可以说quicksort 应该不如其他高效。

另外，考虑到学生在基础编程课程中学习到，递归通常并不太好，因为它会占用过多的内存，等等。因此（尽管这不是一个真正的论点），但这样的想法是快速排序可能不是真的很好，因为它是一种递归算法。

那么，为什么在实践中快速排序优于其他排序算法？它与真实数据的结构有关吗？它与计算机中内存的工作方式有关吗？我知道有些记忆要比其他记忆快，但是我不知道这是否是这种违反直觉的表现的真正原因（与理论估计相比）。

我不会同意quicksort在实践中比其他排序算法要好。

在大多数情况下，Timsort是mergesort / insertion排序之间的混合体，它利用了这样一个事实，即您排序的数据通常始于几乎排序或反向排序的数据。

最简单的快速排序（无随机枢轴）将这种潜在的常见情况视为O（N ^ 2）（通过随机枢轴减少为O（N lg N）），而TimSort可以在O（N）中处理这些情况。

根据C＃中的这些基准，将内置的快速排序与TimSort 进行比较，在大多数排序情况下，Timsort明显更快，而在随机数据情况下，Timsort则稍快一些，如果比较功能特别慢，TimSort会变得更好。我没有再重复这些基准测试，如果quicksort在随机数据的某种组合方面稍胜于TimSort，或者C＃的内置排序（基于quicksort）中有一些古怪的东西使它变慢，我也不会感到惊讶。但是，在对数据进行部分排序时，TimSort具有明显的优势；在对数据进行不部分排序时，TimSort在速度上大致相当于快速排序。

与快速排序不同，TimSort还具有稳定排序的优点。在常规（快速）实现中，TimSort的唯一缺点是使用O（N）与O（lg N）内存。

快速排序被认为是更快的，因为该系数小于任何其他已知算法。没有任何理由或证据，只是没有找到系数较小的算法。确实，其他算法也具有O（n log n）时间，但在现实世界中，系数也很重要。

请注意，由于数学函数的性质，对于小数据插入排序（被认为是O（n ²）的排序）更快。这取决于因机器而异的特定系数。（最后，只有程序集才真正运行。）所以我认为有时候快速排序和插入排序的混合是最快的。

Quicksort不能胜过所有其他排序算法。例如，对于合理数量的数据，自下而上的堆排序（Wegener 2002）优于快速排序，这也是一种就地算法。它也易于实现（至少不比某些优化的quicksort变体难）。

它只是不太知名，您在很多教科书中都找不到它，这也许可以解释为什么它不如quicksort受欢迎。

您不应该只关注最坏情况，也不要关注时间复杂度。它比平均更重要，而不是最坏，而且是关于时间和空间。

快速排序：

• 具有平均 Θ的时间复杂度（Ñ登录Ñ）;
• 可以用Θ（log n）的空间复杂度实现；

还应考虑到，大的O表示法不考虑任何常量，但是在实践中，如果算法快几倍，则确实会有所作为。Θ（n log n）表示该算法在K  n  log（n）中执行，其中K为常数。Quicksort是K 最低 的比较排序算法。

Quicksort通常是一个不错的选择，因为它相当快，而且相当快且易于实施。

如果您真的想非常快速地对大量数据进行排序，那么最好对MergeSort进行一些修改。可以利用外部存储，可以使用多个线程，甚至可以使用进程，但是它们对于代码来说并不简单。

算法的实际性能取决于平台，以及语言，编译器，程序员对实现细节的关注，特定的优化工作等。因此，快速排序的“常量因素优势”不是很明确-它是基于当前可用工具的主观判断，是实际进行比较性能研究的人对“等效实现工作量”的粗略估计。 。

就是说，我相信quicksort（对于随机输入）表现良好，因为它很简单，并且其递归结构相对于缓存友好。另一方面，由于最坏的情况很容易触发，因此快速排序的任何实际使用都需要比其教科书描述所表明的更为复杂：因此，需要使用诸如introsort的修改版本。

随着时间的推移，随着主要平台的变化，不同的算法可能会获得或失去其（不确定的）相对优势。关于相对性能的传统观点可能远远落后于这种转变，因此，如果您真的不确定哪种算法最适合您的应用程序，则应同时实现并测试它们。