Algorithm 算法的运行时间和输入大小如何告诉您算法的时间复杂度？

我做了一个实验，计算了大小为n的数组的排序算法merge-sort和quick-sort的平均运行时间，我不确定如何从结果中证明merge-sort和quick-sort是O（log2（n））

结果如下：

n       mergeSort:       # mergeSort:    quickSort:      quickSort
        mean runtime     mean runtime/   mean runtime    mean runtime/
        (nanosecs)       (n*log2(n))     (nanosecs)      (n*log2(n))
10      49833           1500            17048           513             
100     31245           47              58956           88              
1000    363917          36              158396          15              
10000   2050911         15              1306825         9               
100000  15513647        9               13075212        7               
1000000 183957966       9               153438217       7               
2000000 376220756       8               317621177       7   

---

我注意到，平均运行时间除以n*log2（n）似乎随着n的增加而变得恒定，那么这是否意味着随着n的增加，时间复杂度变得更接近nlog2（n）？

对于基本的双向合并排序，移动的数量是n⌈log2（n）⌉, 但是比较的数量根据数据的不同而不同，但是时间复杂度将是O（n log（n）），并且常数会发生变化。快速排序运行时会受到数据的很大影响，根据您的数字，我假设您正在测试psuedo随机数据

一旦阵列变得如此之大以至于缓存位置成为一个问题，运行时间就会增加。还有影响运行时的合并排序和快速排序的变体。对于较小的数组，自下而上的合并排序比自上而下的快一点，这是因为自上而下将运行边界的索引对推送到堆栈和从堆栈弹出索引对的开销。数组要大得多，大部分时间都花在合并部分，这对于自顶向下和自下而上的合并排序是相同的。

一般来说，您无法通过基准测试来检查算法的复杂性（更不用说证明了）

因为在时间函数的低阶项变得可忽略之前，需要一个大的N，并且不对称行为才会真正出现。同时，大N打破了常时内存访问的一般假设。在现代机器上，这一假设根本站不住脚

对于您的数据，在绘图上，您无法区分线性定律和线性对数定律

---

如果没有看到您在本次评估中使用的实现，很难回答。但是需要记住的一点是，

O（log2（n））

只适用于最坏情况下的运行时复杂性，并且可能不同于，

Ω

和

Θ

。请参阅。@adamb：正相反：对数行为是为了达到预期的复杂性。快速排序的最坏情况是二次排序。