可能有很多原因会优先考虑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台具有较高复杂度的商用机器上运行算法比使用一台具有稍微更好的复杂度的机器有意义。
• 在某些地方（安全性），可能需要复杂性。 没有人希望拥有一种可以快速进行快速哈希处​​理的哈希算法（因为其他人可以更快地对您进行暴力破解）
• 尽管这与复杂性的切换无关，但是应该以防止定时攻击的方式编写一些安全功能。它们大部分都处于同一复杂度类中，但是以某种方式进行修改，以使其总是在更糟的情况下执行某些操作。一个例子是比较字符串是否相等。在大多数应用程序中，如果前几个字节不同，则快速中断是有意义的，但是在安全性方面，您仍然要等到最后告知坏消息。
• 有人为低复杂度算法申请了专利，对于公司而言，使用更高的复杂度比付钱更经济。
• 一些算法可以很好地适应特定情况。例如，插入排序的平均时间复杂度为O(n^2)，比quicksort或mergesort差，但作为一种在线算法，它可以在接收到值（作为用户输入）时有效地对值列表进行排序，而大多数其他算法只能有效地进行操作在值的完整列表上。