为什么程序员更喜欢O（N ^ 3）而不是O（N ^ 2）

Question

我正在为期末考试而学习，档案中有一个问题我无法找到答案：

  

一种算法的运行时间的增长顺序为O（N ^ 2）;该   第二算法的运行时间的增长顺序是O（N ^ 3）。名单   程序员为什么会有三个令人信服的（合乎逻辑的，令人信服的）理由   更喜欢使用O（N ^ 3）算法而不是O（N ^ 2）算法。

Answer 1

我可以想到以下三个原因：

• 易于初步实施。
• 将来易于维护。
• O（N ^ 3）算法可能比O（N ^ 2）算法具有更低的空间复杂度（即，它使用更少的内存）。

Answer 2

可能是＃1的原因：因为O（N ² ）算法具有足够高的常数，对于预期的任务大小，O（N ³ ）版本更快。

Answer 3

以下示例说服O（N³）在某些情况下优于O（N²）。

  

  

1. O（N²）算法编码非常复杂，而如果输入大小为N≤100则实际使用时O（N³）可以足够快

  

2. O（N²）有一个大常数乘以它，例如c = 1000因此对于N = 100，c⋅N2=1000⋅100²=10⁷而如果c = 1则   O（N³）则c⋅N³=10⁶

  

3. 与O（N³）相比，O（N²）算法具有非常高的空间复杂度

  

Answer 4

另一件事是，一些算法有一个很大的常数因素。 O (N^2)可能有一个很大的常数因素，使其无法使用（如果N足够小，如Thorban所说）

Answer 5

选择一种算法的唯一原因不是运行时间的增长顺序。你必须分析：

• 实施起来有多容易
• 所需空间
• 现实生活输入有多大（有时时间差只能观察到实际上从未出现的输入大小）

Answer 6

添加到已发布的答案我想提到缓存行为。由于重复的缓存未命中，特定的内存访问模式可能会慢得多，理论上较慢的算法具有更高的缓存友好的内存访问模式执行得更好。

Answer 7

Big-O是最坏情况的上限。 QuickSort是O（n ^ 2）时间，MergeSort是O（n lgn）时间。但是人们使用QuickSort是因为平均而言它是O（n lgn），其常数低于MergseSort。