可能有很多理由让我们更喜欢大O时间复杂度较高的算法，而不是较低的算法:

• 大多数时候，较低的big-O复杂度很难实现，需要熟练的实现，大量的知识和大量的测试。/li> 中执行的算法比（codeO(1)/code>vs，第一种算法的执行效果更好。例如，矩阵乘法的最佳复杂度是，但据我所知，该常数太高，以至于没有计算库使用它。/li> 还是algorithm./li>并不重要 查找项的时间复杂度，但也有一个二叉树，它在中查找相同的项。即使对于大量的，差异也是微不足道的。/li> 中并需要内存的算法。当n不大时，它可能比时间和空间更可取。问题是，你可以等待很长时间，但高度怀疑你是否能找到一个足够大的RAM来与你的算法一起使用它/li>
• <罢工> 在某些地方（安全性），复杂性可能是一个需求。没有人想要一个哈希算法能够快速的哈希（因为这样其他人就可以强迫你更快）
• 虽然这与复杂度的切换无关，但是一些安全函数应该以防止定时攻击的方式编写。它们大多停留在相同的复杂性类中，但被修改的方式总是需要更坏的情况来做某事。一个例子是比较字符串是否相等。在大多数应用程序中，如果第一个字节不同，那么快速中断是有意义的，但是在安全性方面，您仍然要等到最后才告诉坏消息。/li>
• 有人申请了低复杂度算法的专利，对于一家公司来说，使用更高的复杂度比付钱更经济。/li> 一些算法能很好地适应特定的情况。例如，插入排序的平均时间复杂度为，比quicksort或mergesort差，但作为一种在线算法，它可以在接收到值（作为用户输入）时高效地对值列表进行排序，而大多数其他算法只能高效地对完整的值列表进行操作。/LI>

始终存在隐藏常数，在O(logn)算法中，该常数可以更低。因此在实际应用中，它可以更快地处理真实数据。

还有空间方面的顾虑（例如在烤面包机上运行）。

还有开发人员的时间问题-O(logn)可能更容易实现和验证1000×。

我很惊讶还没有人提到记忆限制应用程序。

可能存在由于其复杂性（即O(1)

我所说的“内存受限”是指您经常访问的数据经常处于缓存外。为了获取这些数据，您必须将实际内存空间中的内存拉到缓存中，然后才能对其执行操作。这个获取步骤通常相当缓慢--比您的操作本身慢得多。

因此，如果您的算法需要更多的操作（然而这些操作是在已经在缓存中的数据上执行的[因此不需要fetch])，就实际的Wall-time而言，它仍然会比您的算法执行的操作更少（这些操作必须在缓存外的数据上执行[因此需要fetch])。