可能有很多理由更喜欢具有较高大 O 时间复杂度的算法而不是较低的算法：

• 大多数时候，较低的 big-O 复杂度更难实现，需要熟练的实施、大量知识和大量测试。
• big-O 隐藏了有关常量的细节10^5：从 big-O 的角度来看，执行 in 的算法比1/10^5 * log(n)( O(1)vs O(log(n)) 更好，但在大多数n情况下，第一个算法会执行得更好。例如，矩阵乘法的最佳复杂度是，O(n^2.373)但常数太高以至于（据我所知）没有计算库使用它。
• 当你计算一些大的东西时，big-O 是有意义的。如果您需要对三个数字的数组进行排序，那么无论您使用O(n*log(n))还是O(n^2)算法都无关紧要。
• 有时小写时间复杂度的优势可以忽略不计。例如，有一个数据结构探戈树，它给出了O(log log N)找到一个项目的时间复杂度，但也有一个二叉树在O(log n). 即使对于巨大的数字，n = 10^20差异也可以忽略不计。
• 时间复杂度不是一切。想象一个运行O(n^2)并需要O(n^2)内存的算法。当 n 不是很大时，随着O(n^3)时间和空间的推移，它可能更可取。O(1)问题是您可以等待很长时间，但非常怀疑您能否找到足够大的 RAM 以将其与您的算法一起使用
• 在我们的分布式世界中，并行化是一个很好的特性。有些算法很容易并行化，有些算法根本不并行化。有时，在 1000 台复杂度更高的商品机器上运行算法比使用复杂度稍高的机器更有意义。
• 在某些地方（安全性），可能需要复杂性。 没有人想要一种哈希算法可以非常快地哈希（因为这样其他人可以更快地暴力破解你）
• 虽然这和 switch 的复杂性无关，但是一些安全函数应该以防止定时攻击的方式编写。它们大多停留在同一个复杂性类别中，但被修改为总是需要更糟的情况才能做某事。一个例子是比较字符串是否相等。在大多数应用程序中，如果第一个字节不同，则快速中断是有意义的，但在安全方面，您仍然会等待最后告诉坏消息。
• 有人为低复杂度算法申请了专利，公司使用更高复杂度的算法比花钱更经济。
• 一些算法很好地适应特定情况。例如，插入排序的平均时间复杂度为O(n^2)，比快速排序或归并排序差，但作为一种在线算法，它可以在接收到值列表（作为用户输入）时有效地对值列表进行排序，而大多数其他算法只能有效地操作在完整的值列表中。