最合适的排序算法答案

【问题标题】：Best suitable sorting algorithm最合适的排序算法
【发布时间】：2014-05-07 06:52:03
【问题描述】：

我有一个可能包含大约 1-5 百万条记录的哈希表。我需要遍历它以选择其中的一些条目，然后按某种顺序对它们进行排序。我打算使用一个链表来维护一个指向哈希表中我必须排序的条目的指针列表。但是使用链表，我遇到的唯一可用的排序选项是合并排序。但是考虑到列表可能包含大约 500 万条记录，是否应该使用归并排序？我没有限制只使用链表来维护指针列表。我也可以使用数组，以便可以使用堆排序。但是考虑到这个完整的操作非常频繁并且它的不同实例可以并行运行，决定这个数组的大小将是一项具有挑战性的任务。此外，从哈希表中过滤出用于排序的条目数可以从 1 到几乎所有的哈希表中的记录不等。有人可以建议我哪种方法最适合这里吗？

【问题讨论】：

您是否考虑过在 Hadoop 集群上使用 terasort？
每条记录的大小是多少？您使用链表（这个 DS 称为 LinkedHashSet）和使用合并排序的方法对我来说听起来非常好，是不是在您的实验上花费了太多时间？
链表中的每个元素只包含 2 个指针：指向哈希表条目的指针和指向下一个节点的指针。所以在 64 位系统上，每个记录大小为 16 字节。我没有测试花费的时间，但担心堆栈内存上太多的 16 字节节点是否会导致问题。（AFAIK 合并排序使用递归，因此仅使用堆栈）
合并排序是一个很好的选择。使用链表，排序不需要额外的空间。并且该算法非常有效。在现代硬件上，使用归并排序对 500 万个项目进行排序是微不足道的。 “相当频繁”的频率是多少？

标签： c algorithm sorting data-structures

【解决方案1】：

先尝试最简单的方法：

实现一个典型的动态数组，使用realloc() 进行增长，并且可能使用典型的增长时双重分配方案。增长到一百万个元素将需要大约 20 次重新分配。
使用qsort()对数组进行排序。

然后分析它，看看它的痛处。如果您对内存不敏感，请增加数组的初始分配。

【讨论】：

给定一个 4 字节的指针大小，最大数组大小为 500 万，以及一台现代机器（即几 GB 的 DRAM），简单地从分配 20MB 的数组开始并不是不合理的.这将比使用realloc 敲打内存要快。
但是考虑到这个操作可能并行运行，我需要大约 10-12 个 20MB 大小的数组。这会是一个不错的选择吗？
只要数组适合物理内存（即不被虚拟内存管理器交换到磁盘），那么这种方法就可以很好地工作。 20MB 的 12 个数组是 0.25GB，因此除非您已经在内存限制附近运行，否则这应该不是问题。