在标准的算法当然我们被教导快速排序是平均和ø （Ñ 2）在最坏的情况下。同时，还研究了其他排序算法，它们在最坏的情况下为O （n log n ）（例如mergesort和heapsort），在最坏的情况下甚至是线性时间（例如bubbleort），但还有一些额外的内存需求。$O(n \log n)$$O(n^2)$$O(n \log n)$

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

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

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

更新1：一个规范的答案是说，平均情况的所涉及的常数小于其他O （n log n ）算法所涉及的常数。但是，我还没有看到用正确的计算代替仅凭直觉的想法的适当理由。$O(n\log n)$$O(n\log n)$

无论如何，正如某些答案所暗示的那样，似乎真正的区别发生在内存级别，在这种级别上，实现利用了计算机的内部结构，例如使用高速缓存比RAM快。讨论已经是有趣的，但我还是喜欢看关于内存管理更详细，因为它似乎是在回答有什么关系。

更新2：有几个网页提供了排序算法的比较，其中有些比其他网页更出色（最著名的是sorting-algorithms.com）。除了提供不错的视觉辅助外，这种方法也无法回答我的问题。

简短答案

缓存效率参数已经详细说明。此外，还有一个内在的论点，为什么Quicksort快速。如果喜欢用两个“交叉指针”，实现如在这里，内循环有一个非常小的身体。由于这是最常执行的代码，因此很值得。

长答案

首先，

在平均情况不存在！

由于最佳和最坏情况在实践中很少会出现极端情况，因此需要进行平均情况分析。但是任何平均案例分析都假设输入有一定分布！对于排序，典型的选择是随机排列模型（在维基百科上是默认的）。

为什么使用符号？$O$

丢弃算法分析中的常量的主要原因之一是：如果我对准确的运行时间感兴趣，则需要所有相关基本操作的（相对）成本（即使仍然忽略缓存问题，现代处理器中的流水线处理……）。数学分析可以计算每条指令执行的频率，但是单条指令的运行时间取决于处理器的详细信息，例如32位整数乘法是否需要与加法一样长的时间。

有两种解决方法：

1. 修复某些机器模型。

   这是在唐· 克努斯（Don Knuth）的书系列“计算机编程的艺术”中完成的，该书是作者发明的人工“典型”计算机。在第3卷中，您可以找到许多排序算法的准确平均案例结果，例如

   • 快速排序：$11.667(n+1)\ln(n)-1.74n-18.74$
   • 合并排序：$12.5 n \ln(n)$
   • 堆排序： $16 n \ln(n) +0.01n$
   • Insertionsort： ^{[ 来源 ]}$2.25n^2+7.75n-3ln(n)$
     

   这些结果表明Quicksort最快。但是，它仅在Knuth的人造机器上得到证明，对于x86 PC而言，它不一定意味着任何东西。另请注意，对于小量输入，算法的相关性有所不同：
   
   ^{[ 源 ]}

2. 分析抽象的基本操作。

   对于基于比较的排序，通常是交换和键比较。在罗伯特·塞奇威克（Robert Sedgewick）的书中，例如“算法”，就是采用了这种方法。你在那里找到

   • $2n\ln(n)$$\frac13n\ln(n)$
   • $1.44n\ln(n)$$8.66n\ln(n)$
   • $\frac14n^2$$\frac14n^2$

   如您所见，这并不容易将算法进行比较，以进行精确的运行时分析，但是结果与机器详细信息无关。

其他输入分布

如上所述，平均情况总是与某种输入分布有关，因此可以考虑随机排列以外的情况。例如，已经对具有相同元素的Quicksort进行了研究，并且有一篇不错的文章介绍了Java中的标准sort函数

关于这个问题可以提出很多观点。

快速排序通常很快

$O(n^2)$

$n-1$$O(n \log n)$

快速排序通常比大多数排序更快

$O(n \log n)$$O(n^2)$$n$

$O(n \log n)$$O(\frac{n}{B} \log (\frac{n}{B}))$$B$

这种高速缓存效率的原因是它线性扫描输入并线性划分输入。这意味着我们在读取每个加载到缓存中的数字之前，可以充分利用我们所做的每个缓存加载，然后再将该缓存交换为另一个。特别是，该算法不考虑缓存，可以为每个缓存级别提供良好的缓存性能，这是另一个优势。

$O(\frac{n}{B} \log_{\frac{M}{B}} (\frac{n}{B}))$$M$$k$

Quicksort通常比Mergesort快

这种比较完全是关于恒定因素的（如果我们考虑典型情况）。特别是，选择是在Quicksort枢轴的次优选择与Mergesort的整个输入的副本之间的选择（或避免这种复制所需的算法复杂性）之间。事实证明，前者效率更高：这背后没有理论依据，只是碰巧更快。

$n$$O(\log n)$$O(n)$

最后，请注意，Quicksort对恰好按正确顺序输入的内容稍有敏感，在这种情况下，它可以跳过某些交换。Mergesort没有任何此类优化，与Mergesort相比，它还使Quicksort更快。

使用适合您需求的分类

结论：没有排序算法总是最佳的。选择适合您需求的任何一种。如果您需要一种在大多数情况下最快的算法，并且不介意在极少数情况下它可能会变得有点慢，并且不需要稳定的排序，请使用Quicksort。否则，请使用更适合您需求的算法。

在我大学的一本编程教程中，我们要求学生比较quicksort，mergesort，insert sort和Python内置的list.sort（称为Timsort）的性能。实验结果使我深感惊讶，因为内置list.sort的性能比其他排序算法要好得多，即使在实例很容易使quicksort，mergesort崩溃的情况下也是如此。因此，断定通常的快速排序实施是最佳实践为时尚早。但是我敢肯定，Quicksort或它的某些混合版本可以更好地实现。

这是David R. MacIver撰写的一篇不错的博客文章，解释了Timsort是自适应mergesort的一种形式。

我认为与其他排序算法相比，QuickSort如此之快的主要原因之一是因为它对缓存友好。QS处理数组的某个片段时，它将访问该片段的开始和结尾处的元素，然后移向该片段的中心。

因此，当您开始时，您访问数组中的第一个元素，并将一块内存（“位置”）加载到缓存中。当您尝试访问第二个元素时，它很可能已经在缓存中，因此非常快。

其他算法（例如堆排序）不能像这样工作，它们会在数组中跳很多，这会使它们变慢。

其他人已经说过，Quicksort 的渐近平均运行时间（以常数表示）比其他排序算法（在某些设置下）更好。

$\cal{O}(n \log n)$

注意，Quicksort有许多变体（例如，参见Sedgewick的论文）。它们在不同的输入分布上（统一，几乎排序，几乎反向排序，许多重复...）表现不同，其他算法可能对某些算法更好。

$k \approx 10$

$O(n \lg n)$

ps：确切地说，优于其他算法取决于任务。对于某些任务，最好使用其他排序算法。

也可以看看：

• 快速排序与其他排序算法的比较

• 堆排序与其他排序算法的比较

$\Theta(n^2)$$\Theta(n\log n)$

第二个原因是它可以执行in-place排序并在虚拟内存环境中很好地工作。

更新：：（在Janoma和Svick的评论之后）

为了更好地说明这一点，让我举一个使用“合并排序”的示例（因为我认为“合并排序”是继快速排序之后的下一个被广泛采用的排序算法），并告诉您额外的常量来自何处（据我所知）以及为什么我认为快速排序更好）：

考虑以下顺序：

12,30,21,8,6,9,1,7. The merge sort algorithm works as follows:

(a) 12,30,21,8    6,9,1,7  //divide stage
(b) 12,30   21,8   6,9   1,7   //divide stage
(c) 12   30   21   8   6   9   1   7   //Final divide stage
(d) 12,30   8,21   6,9   1,7   //Merge Stage
(e) 8,12,21,30   .....     // Analyze this stage

如果您仔细查看最后一个阶段是如何发生的，则将前12个与8相比较，然后将8个较小，因此优先。现在12又是21，接下来是12，依此类推。如果您进行最终合并，即4个元素与其他4个元素，则它将产生大量的EXTRA比较作为常量，这在Quick Sort中不会发生。这就是为什么首选快速排序的原因。

我在处理现实世界数据时的经验是，快速排序是一个糟糕的选择。Quicksort适用于随机数据，但现实世界中的数据通常不是随机数据。

早在2008年，我就跟踪了一个由于使用quicksort导致的软件漏洞。过了一会儿，我写了插入排序，快速排序，堆排序和合并排序的简单方法，并对它们进行了测试。在处理大型数据集时，我的合并排序优于其他所有排序。

从那时起，合并排序就是我选择的排序算法。优雅 实施起来很简单。这是一个稳定的排序。它不会像quicksort那样退化为二次行为。我改用插入排序对小数组进行排序。

在很多情况下，我发现自己的想法是，给定的实现对快速排序的效果出奇地好，只是发现它实际上不是快速排序。有时，实现会在快速排序和其他算法之间切换，有时甚至根本不使用快速排序。例如，GLibc的qsort（）函数实际上使用合并排序。仅当分配工作空间失败时，它才会退回到就地快速排序中，代码注释将其称为“较慢的算法”。

编辑：诸如Java，Python和Perl之类的编程语言也使用合并排序，或更确切地说，使用派生类（例如Timsort或大集合的合并排序，小集合的插入排序）。（Java还使用双轴快速排序，这比普通快速排序要快。）

1-快速分类就位（不需要固定的数量，也不需要额外的内存。）

2-快速排序比其他有效的排序算法更易于实现。

3-与其他有效的排序算法相比，快速排序在运行时间上具有较小的恒定因子。

更新：对于合并排序，您需要执行一些“合并”，在合并之前需要额外的数组来存储数据。但是很快，您就不会。这就是为什么可以进行快速排序。对于合并还进行了一些额外的比较，这些比较增加了合并排序中的常量因子。

在什么条件下特定的排序算法实际上是最快的算法？

$\Theta(\log(n)^2)$$\Theta(n \cdot \log(n)^2)$

$\Theta(n \cdot k)$$\Theta(n \cdot m)$$k=2^{\#number\_of\_Possible\_values}$$m = \#maximum\_length\_of\_keys$

3）基础数据结构是否由链接的元素组成？是的->始终使用就地合并排序。链接数据结构易于实现固定大小或自适应的（即自然的）自下而上的归并合并各种不同的域，因为它们从不需要在每个步骤中复制整个数据，并且也不需要递归，所以它们都是比任何其他基于比较的常规排序都快，甚至比快速排序快。

$\Theta(n)$

5）底层数据的大小可以绑定到小到中等大小吗？例如n是否小于10,000 ... 100,000,000（取决于基础架构和数据结构）？是->使用bionic排序或Batcher奇偶归并排序。转到1）

$\Theta(n)$$\Theta(n^2)$$\Theta(n \cdot \log(n)^2)$已知最坏的运行时间，或者尝试进行梳理排序。我不确定shell排序还是comb排序在实践中都不会表现得很好。

$\Theta(\log(n))$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n^2)$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n \cdot \log(n))$

$\Theta(n \cdot \log(n))$

quicksort的实现提示：

$\Theta(n)$$\Theta(\log(n))$$\Theta(n^{\log_k(k-1)})$

2）存在快速排序的自下而上的迭代变体，但是AFAIK具有与自上而下相同的渐近空间和时间边界，并且其他方面也难以实现（例如，显式管理队列）。我的经验是，出于任何实际目的，这些都不值得考虑。

mergesort的实现提示：

1）自上而下的mergesort总是比自上而下的mergesort更快，因为它不需要递归调用。

2）可以通过使用双缓冲区并切换缓冲区来加快非常幼稚的mergesort的速度，而不是在每个步骤之后都将数据从时态数组中复制回来。

3）对于许多实际数据，自适应合并排序比固定大小的合并排序要快得多。

$\Theta(k)$$\Theta(\log(k))$$\Theta(1)$$\Theta(n)$

从我写的内容来看，很明显，快速排序通常不是最快的算法，除非同时满足以下条件：

1）可能的值不止一个

2）基础数据结构未链接

3）我们不需要稳定的订单

4）数据足够大，以至于双音分类器或Batcher奇偶合并合并的轻微次优渐近运行时间开始

5）数据几乎没有排序，并且不包含更大的已排序部分

6）我们可以从多个位置同时访问数据序列

$\Theta(\log(n))$$\Theta(n)$

ps：有人需要帮助我格式化文本。

大多数排序方法都必须在短时间内移动数据（例如，合并排序在本地进行更改，然后合并这一小块数据，然后合并一个更大的数据..）。因此，如果数据离其目的地很远，则需要进行许多数据移动。

$a \le b$