.net 小型阵列的快速稳定排序（32或64个元素以下）

一般认为，对于足够小的数组，插入排序是最好的。例如，对最多64个元素的数组使用（二进制）插入排序；发件人：

一些分治算法，如快速排序和合并排序，通过递归地将列表划分为较小的子列表进行排序。在实践中，这些算法的一个有用优化是使用插入排序对小的子列表进行排序，因为插入排序优于这些更复杂的算法。插入排序具有优势的列表大小因环境和实现而异，但通常在8到20个元素之间

这是真的吗？还有更好的选择吗

---

如果这很大程度上取决于平台，我对.NET最感兴趣。

因为.NET是一种不编译为原始机器代码的语言。我认为调用API函数（使用原生代码）可能是最快的方法

< p>是的，这是我在算法类中所学到的，这也是C++中如何实现排序的。来自维基百科：

2000年6月SGI C++标准 模板库stl_algo.h 不稳定排序的实现 使用 切换到heapsort的递归深度 作为参数传递，中间值为-3 枢轴选择和Sedgewick 最终插入排序过程。元素 切换到简单模式的阈值 插入排序为16

---

我去年做了一些非正式的性能测试，C++的STLST:：排序的速度是数组的两倍。我不知道.Net Realth.Set是如何实现的，但是在.NET中，数组中的访问需要一个边界检查，不像C++，这在很大程度上可以解释性能差异。

< P>我发现它实际上取决于比较函数需要做多少工作。比如，如果我间接地对工作表中的行进行排序，每次比较都涉及到获取一行，然后比较可能的几列，可能混合了数字和字符串比较，那么速度可能会变慢

另一方面，如果数组的长度较短，则取决于每秒需要对其进行排序的次数，因为即使与可能的情况相比，它的速度相对较慢，您也可能永远不会注意到差异

如果我有任何疑问，我只需要编写一个合并排序，然后使用它。我有过qsort不稳定的糟糕经历，有时需要很长时间。手工编码的合并排序简单、可靠且足够快。

对于小列表，没有比插入排序更快的O（n logn）算法了。然而，有一些O（n^2）算法确实存在竞争。值得注意的是，选择排序并不是其中之一，尽管在掉期和移动价格昂贵的罕见情况下，选择排序很好。冒泡排序和变体也很糟糕

---

网络排序：一种排序算法，总是稳定的，没有分支。它的总体规格很糟糕，但没有分支意味着在最微小的列表中表现出色。基本情况是：<代码>如果（AI想知道在C++上对C元素的40元素数组进行排序会有什么不同，然后我想知道它是否真的有什么关系。@ SrRoCo我已经在考虑它，研究Woto的混合模式等，以避免API调用的开销或最小化。