这里的答案具有一些基本统计数据，这些数据显示打包的链表将通过合并排序执行非常快速的排序：
What's the fastest algorithm for sorting a linked list?
我想知道是否有任何技术（诸如垃圾收集之类的后台作业）可以最佳地重组链接列表，从而在运行时变得更加紧凑。
答案 0 :(得分：2)
您是否要节省空间或时间？您总是可以分配一个新的“打包”列表，然后将碎片列表复制/排序到新的“打包”列表中。
我想知道先前的答案中的结果，以为打包列表上的合并排序正在对先前测试中已经排序的列表进行操作。在我的测试中，我从一个大的（大于缓存的）打包链接列表开始，其中值是伪随机整数，结果是一个排序的打包列表，其中节点是伪随机排序的，我称之为“分散”（非缓存友好）链接列表。然后，我用另一组伪随机数填充该列表，以测试该“分散”链接列表上的合并排序。
最快的链表排序（假设接近随机数据）是一种自下而上的合并排序，它使用一小串（25到32）列表指针（或引用）。有关基本算法的Wiki文章：
https://en.wikipedia.org/wiki/Merge_sort#Bottom-up_implementation_using_lists
这里的问题是合并排序正在使用“分散的”链接列表，该列表不是缓存友好的。
如先前的回答中所述，但与结果冲突，将链表复制到数组，然后使用快速排序或合并排序对数组进行排序应该更快（这些数组排序方法中的任何一个都将被缓存）友好），然后从现在已排序的数组中创建一个新的已排序打包列表。假定空间不是分配数组或打包列表的问题。
其他替代方法是创建一个指向节点的指针数组以对列表中的数据进行排序（无需重新链接节点），或者创建一个指向节点的指针数组，对指针数组进行排序，然后重新链接列表节点根据指针。同样，这里的问题是这些方法将与“分散”链接列表一起使用，该列表不是缓存友好的。