快速排序，不要打扰？

尤其是在编写“标准”（非HPC）应用程序时，您会考虑选择哪种排序算法，还是仅仅考虑使用快速排序（大多数库都将其称为排序）？在特定情况下，在某种程度上可能是有利可图的，但另一方面，适当的优化需要一些时间来分析问题并制定基准。

通常，除非有特殊的需要，否则使用默认方法，除非IMHO沿途使所有内容更具可读性/可理解性。

如果您遇到（或者在某些情况下，强烈怀疑）您遇到了性能问题，那就是增加复杂性的时候了。

另一方面，如果您使用的语言不够低，就没有针对需要排序的对象的内置排序，则尝试选择一个或两个覆盖您所有基础的对象并实现它们。

始终调用提供的库例程，除非您有非常非常好的理由不这样做（并且您需要记录为什么这样做）。

这是因为排序算法很难完全正确。Java快速排序中有一个错误，它包含非常大的数据集，Sun可以识别，修复并交付给客户，因此您不必这样做。

Java 7中的默认排序也已升级为更新更好的排序。也免费。

除非默认排序对您证明不够好，否则请坚持使用。

在一次会议上，我听到了一个很好的故事。

在Microsoft，有人正在编写一个VB应用程序（例如VB 3），并邮寄了一堆人说他有很多价值观，他希望这些价值观按顺序出现在组合框中，他应该如何去做。

每个人都投入了旧的计算机科学课本，查找高效的例程并将其移植到Visual Basic并将其邮寄给他。有人刚寄回邮件“组合框中有多少个值？”。

回复“大约50”。

“只需将已排序的属性设置为TRUE”。

在99.9999％的实例中，最好使用库，控件或SQL select进行排序，因为库例程与您编写的任何内容之间的性能差异可以忽略不计，并且工作量和维护开销将大大超过其后果。

现在该抽出有关过早优化的经典报价了。在大多数情况下，这并不重要。哎呀，由于这些天的CPU速度，您可能可以对大多数数据集进行冒泡排序，而实际上并没有引起太多注意。但是，当您对非常大的数据集进行排序并且排序性能开始成为一个问题时，那么您绝对应该考虑其他选择。

虽然显然对位和时间片无关紧要。我发现合并排序比quicksort更容易编写和理解。因此，如果我要编写自己的排序算法，则会使用该算法。

至少在一个能干的书面库中，我希望内置程序sort可以作为Introsort而不是Quicksort 来实现。差异很少有多大关系，但是Introsort消除了Quicksort在最坏情况下的最坏情况，对较常见的情况影响最小。

但是，要回答您的问题：是的-这通常是您应该开始的地方，并且直到/除非获得分析器结果表明这是一个问题，才应该保留它。