讲师：张云浩github主页

为什么要学习数据结构和算法？

数据结构和算法几乎存在于程序开发中的所有地方，举个例子：

实现抖音直播排行榜功能，某个时间段内，直播间礼物数TOP10房间获得奖励，需要在每个房间展示排行榜。

解决方案：

礼物数量存储在Redis-zset中，使用skiplist使得元素整体有序
使用Redis集群，避免单机压力过大,使用主从算法、分片算法保证集群元信息的稳定，使用一致性算法
后端使用缓存算法(LRU)降低 Redis压力，展示房间排行榜

什么是最快的排序算法？

Python-timsort C++-introsort Rust-pdqsort

Go的排序算法有没有提升空间？

Go(<=1.18)-introsort

问题思考？

Go 1.19的排序算法是如何设计的?

生产环境中使用的的排序算法和课本上的排序算法有什么区别?

Go语言的排序算法是快速排序么?

经典排序算法

插入排序

插入排序将元素不断插入已经排序好的array中：

起始只有一个元素5，其本身是一个有序序列
后续元素插入有序序列中，即不断交换，直到找到第一个比其小的元素

时间复杂度如下：

Best	Avg	Worst
O(n)	O(n^2)	O(n^2)

快速排序

快速排序基于分治思想，不断分割序列直到序列整体有序：

选定一个pivot(轴点)
使用pivot 分割序列，分成元素比 pivot大和元素比 pivot 小两个序列

时间复杂度如下：

Best	Avg	Worst
O(n*logn)	O(n*logn)	O(n^2)

堆排序

利用堆的性质形成的排序算法：

构造一个大顶堆
将根节点(最大元素)交换到最后一个位置，调整整个堆，如此反复

Best	Avg	Worst
O(n*logn)	O(n*logn)	O(n*logn)

插入排序平均和最坏情况时间复杂度都是O(n^2)，性能不好；快速排序整体性能处于中间层次；堆排序性能稳定。

Benchmark

实际测试场景，根据序列元素排列情况划分：

完全随机的情况(random)
有序/逆序的情况(sorted/reverse)
元素重复度较高的情况(mod8)

在此基础上，还需要根据序列长度的划分(16/128/1024)。

Benchmark-random测试结果：

序列长度	算法类型	次数	平均时长
短序列	BenchmarkRandom/InsertionSort_16BenchmarkRandom/QuickSort_16BenchmarkRandom/HeapSort_16	701883844787634673740	170.7 ns/op267.9 ns/op257.2 ns/op
中序列	BenchmarkRandom/InsertionSort_128BenchmarkRandom/QuickSort_128BenchmarkRandom/HeapSort_128	231906404396324348	5188 ns/op2966 ns/op3558 ns/op
长序列	BenchmarkRandom/InsertionSort_1024BenchmarkRandom/QuickSort_1024BenchmarkRandom/HeapSort_1024	39993737129060	285938 ns/op32209 ns/op41069 ns/op

总结： 插入排序在短序列中速度最快，快速排序在其他情况中速度最快，堆排序速度与最快算法差距不大。

Benchmark-sorted测试结果：

序列长度	算法类型	次数	平均时长
短序列	BenchmarkRandom/InsertionSort_16BenchmarkRandom/QuickSort_16BenchmarkRandom/HeapSort_16	4124292374844329987447	29.18 ns/op176.3 ns/op120.3 ns/op
中序列	BenchmarkRandom/InsertionSort_128BenchmarkRandom/QuickSort_128BenchmarkRandom/HeapSort_128	11491232282652976645	104.3 ns/op4099 ns/op1085 ns/op
长序列	BenchmarkRandom/InsertionSort_1024BenchmarkRandom/QuickSort_1024BenchmarkRandom/HeapSort_1024	1845013614876885	6848.8 ns/op180353 ns/op15476 ns/op

总结： 插入排序在序列已经有序的情况下最快。

最终结论：

所有短序列和元素有序情况下，插入排序性能；最好在大部分的情况下，快速排序有较好的综合性能；几乎在任何情况下，堆排序的表现都比较稳定。

那么针对以上结论，我们是不是可以根据不同的场景使用不同的排序算法呢？更进一步，我们是不是可以自己封装一个排序算法？

从零开始打造pdqsort

pdqsort (pattern-defeating-quicksort)是一种不稳定的混合排序算法，它的不同版本被应用在C++BOOST、Rust 以及Go 1.19中。它对常见的序列类型做了特殊的优化，使得在不同条件下都拥有不错的性能。

Version1

结合三种排序方法的优点：

对于短序列(小于一定长度)我们使用插入排序。
其他情况，使用快速排序来保证整体性能。
当快速排序表现不佳时，使用堆排序来保证最坏情况下时间复杂度仍然为O(n*logn)

细节思考：

短序列的具体长度是多少呢?

12~32，在不同语言和场景中会有不同，在泛型版本根据测试选定24。

如何得知快速排序表现不佳，以及何时切换到堆排序?

当最终pivot的位置离序列两端很接近时(距离小于length/8)判定其表现不佳，当这种情况的次数达到limit (即bits.Len(length))时，切换到堆排序。

第一版pdqsort流程如下：

对于短序列(<=24)我们使用插入排序
其他情况，使用快速排序(选择首个元素作为pivot)来保证整体性能
当快速排序表现不佳时(limit==O)，使用堆排序来保证最坏情况下时间复杂度仍然为O(n*logn)

如何让pdqsort速度更快?

尽量使得QuickSort的pivot为序列的中位数，即改进choose pivot
Partition速度更快，即改进partition，但是此优化在Go表现不好，略

Version2

在一般情况下都是使用的快速排序，那么显而易见快速排序的效率决定着整体排序的效率，因此针对快速排序进行优化。我们思考关于pivot的选择？

使用首个元素作为poivot(最简的的方案)，实现简单，但是往往效果不好，例如在sorted情况下性能很差
遍历数组，寻找真正的中位数，遍历比对代价很高，性能不好

对于以上两种方案，需要平衡寻找pivot所需要的开销与pivot带来的性能优化。

我们也可以根据序列的长度不同，采取不同的pivot选择方案：

短序列(<=8)，选择固定元素。
中序列(<=50)，采样三个元素。
长序列(>50)，采样九个元素。

通过采样我们能探知当前序列的状态，根据序列的不同状态采取不同的操作，例如：

如果采样的元素都是逆序排列，那么序列可能已经逆序，可以视情况翻转整个序列。
如果采样的元素都是顺序排列，那么序列可能已经有序，可以视情况使用插入排序。

插入排序实际使用partiallnsertionSort，即有限制次数的插入排序。

第二版pdqsort流程如下：

Version3

如何优化重复元素很多的情况？

采样pivot的时候检测重复度?不是很好，因为采样数量有限，不一定能采样到相同元素。如果两次partition生成的pivot相同，即partition进行了无效分割，此时认为pivot的值为重复元素。

重复元素较多的情况(partitionEqual)：当检测到此时的pivot和上次相同时(发生在leftSubArray)，使用partitionEqual将重复元素排列在一起，减少重复元素对于pivot选择的干扰。
当pivot选择策略表现不佳时，随机交换元素：避免一些极端情况使得QuickSort总是表现不佳，以及一些黑客攻击情况。

第三版pdqsort(go 1.19 default)流程如下：

各种排序算法时间复杂度对比：

Type	Best	Avg	Worst
InsertionSort	O(n)	O(n^2)	O(n^2)
QuickSort	O(n*logn)	O(n*logn)	O(n^2)
HeapSort	O(n*logn)	O(n*logn)	O(n*logn)
PdqSort	O(n)	O(n*logn)	O(n*logn)

EC2 t2.micro (1 vCPU, 1 GiB mem)，goos: linux, goarch: amd64

name                       old time/op    new time/op    delta
Random/sort_64               6.57µs ± 2%    6.67µs ± 1%   +1.52%  (p=0.002 n=10+9)
Random/sort_256              30.6µs ± 5%    31.2µs ± 5%     ~     (p=0.052 n=10+10)
Random/sort_1024              142µs ± 1%     144µs ± 1%   +1.73%  (p=0.000 n=10+10)
Random/sort_4096              674µs ± 1%     674µs ± 0%     ~     (p=0.739 n=10+10)
Random/sort_65536            14.2ms ± 0%    14.1ms ± 0%   -0.68%  (p=0.000 n=10+10)
Sorted/sort_64               2.87µs ± 4%    1.31µs ± 8%  -54.49%  (p=0.000 n=10+10)
Sorted/sort_256              11.7µs ± 0%     2.4µs ± 3%  -79.34%  (p=0.000 n=10+10)
Sorted/sort_1024             54.8µs ± 6%     7.0µs ± 2%  -87.31%  (p=0.000 n=10+10)
Sorted/sort_4096              253µs ± 1%      25µs ± 1%  -90.31%  (p=0.000 n=9+10)
Sorted/sort_65536            5.53ms ± 0%    0.35ms ± 1%  -93.61%  (p=0.000 n=9+10)
NearlySorted/sort_64         3.36µs ± 1%    3.13µs ± 5%   -6.69%  (p=0.000 n=8+10)
NearlySorted/sort_256        14.7µs ± 1%    13.2µs ± 1%   -9.63%  (p=0.000 n=9+8)
NearlySorted/sort_1024       69.2µs ± 4%    59.6µs ± 1%  -13.94%  (p=0.000 n=10+8)
NearlySorted/sort_4096        320µs ± 1%     283µs ± 1%  -11.45%  (p=0.000 n=9+10)
NearlySorted/sort_65536      6.79ms ± 0%    6.03ms ± 1%  -11.17%  (p=0.000 n=9+10)
Reversed/sort_64             3.25µs ± 3%    1.53µs ± 8%  -52.90%  (p=0.000 n=8+10)
Reversed/sort_256            12.7µs ± 2%     3.1µs ± 3%  -75.43%  (p=0.000 n=10+10)
Reversed/sort_1024           55.5µs ± 1%     9.8µs ± 3%  -82.40%  (p=0.000 n=9+10)
Reversed/sort_4096            265µs ± 1%      36µs ± 3%  -86.58%  (p=0.000 n=10+8)
Reversed/sort_65536          5.68ms ± 0%    0.51ms ± 0%  -90.98%  (p=0.000 n=9+10)
NearlyReversed/sort_64       4.44µs ± 1%    3.93µs ± 2%  -11.38%  (p=0.000 n=7+9)
NearlyReversed/sort_256      21.1µs ± 1%    16.8µs ± 1%  -20.16%  (p=0.000 n=10+10)
NearlyReversed/sort_1024     96.8µs ± 3%    77.3µs ± 2%  -20.13%  (p=0.000 n=10+9)
NearlyReversed/sort_4096      453µs ± 1%     365µs ± 1%  -19.42%  (p=0.000 n=10+10)
NearlyReversed/sort_65536    9.22ms ± 0%    7.40ms ± 2%  -19.75%  (p=0.000 n=8+10)
Mod8/sort_64                 3.39µs ± 4%    3.32µs ± 7%     ~     (p=0.190 n=9+10)
Mod8/sort_256                12.5µs ± 1%    10.3µs ± 1%  -17.87%  (p=0.000 n=10+10)
Mod8/sort_1024               49.1µs ± 6%    39.6µs ± 6%  -19.43%  (p=0.000 n=9+10)
Mod8/sort_4096                200µs ± 2%     149µs ± 2%  -25.53%  (p=0.000 n=10+10)
Mod8/sort_65536              2.98ms ± 0%    2.20ms ± 1%  -26.34%  (p=0.000 n=10+10)
AllEqual/sort_64             1.68µs ± 6%    1.33µs ± 7%  -20.73%  (p=0.000 n=10+10)
AllEqual/sort_256            3.94µs ± 1%    2.49µs ± 3%  -36.69%  (p=0.000 n=9+10)
AllEqual/sort_1024           12.9µs ± 1%     6.9µs ± 3%  -46.14%  (p=0.000 n=9+10)
AllEqual/sort_4096           46.4µs ± 5%    24.8µs ± 1%  -46.68%  (p=0.000 n=10+8)
AllEqual/sort_65536           697µs ± 0%     352µs ± 1%  -49.50%  (p=0.000 n=10+10)
[Geo mean]                   78.7µs         40.8µs       -48.17%

思考

高性能的排序算法是如何设计的?

根据不同情况选择不同策略，取长补短。

生产环境中使用的的排序算法和课本上的排序算法有什么区别?

理论算法注重理论性能，例如时间、空间复杂度等。生产环境中的算法需要面对不同的实践场景，更加注重实践性能。

Go语言(<=1.18)的排序算法是快速排序么?

实际一直是混合排序算法，主体是快速排序。Go <= 1.18时的算法也是基于快速排序，和 pdqsort的区别在于fallback时机、pivot选择策略、是否有针对不同pattern优化等。

参考资料：

排序算法实践|青训营笔记