sharptooth是正确的，O(1)是可能的最佳性能。然而，这并不意味着一个快速的解决方案，只是一个固定时间的解决方案。

一个有趣的变种，也许是真正的建议，是随着人口的增长，哪些问题会变得更容易。我能想出一个虽然是做作的半开玩笑的答案:

一组中有两个人生日相同吗?当n超过365时，返回true。虽然小于365，这是O(nln n)。也许不是一个很好的答案，因为问题不会慢慢变得简单，而是变成O(1)对于n > 365。

我相信量子算法可以通过叠加“一次”进行多次计算……

我怀疑这是一个有用的答案。

O(1)仅仅表示“常数时间”。

当你给循环[1]添加一个早期退出时，你(在大O符号中)把一个O(1)算法变成了O(n)算法，但使它更快。

诀窍是一般情况下，常数时间算法是最好的，线性算法比指数算法好，但对于n很小的时候，指数算法可能更快。

1:假设这个例子的列表长度是静态的

如果解决方案存在，它可以在常数时间=立即准备和访问。例如，如果您知道排序查询是针对倒序的，则使用LIFO数据结构。然后，假设选择了适当的模型(LIFO)，数据就已经排序了。

我猜小于O(1)是不可能的。算法所花费的任何时间都称为O(1)。但是对于O(1/n)下面的函数呢。(我知道这个解决方案中已经出现了许多变体，但我猜它们都有一些缺陷(不是主要的，它们很好地解释了这个概念)。这里有一个，只是为了方便讨论:

def 1_by_n(n, C = 10):   #n could be float. C could be any positive number
  if n <= 0.0:           #If input is actually 0, infinite loop.
    while True:
      sleep(1)           #or pass
    return               #This line is not needed and is unreachable
  delta = 0.0001
  itr = delta
  while delta < C/n:
    itr += delta

因此，随着n的增加，函数将花费越来越少的时间。此外，如果输入实际为0，则函数将永远返回。

有人可能会说，这将受到机器精度的限制。因此，由于c eit有一个上界，它是O(1)。但我们也可以绕过它，通过在字符串中输入n和C。加法和比较是对字符串进行的。用这个方法，我们可以把n减小到任意小。因此，即使忽略n = 0，函数的上限也是无界的。

我也相信我们不能说运行时间是O(1/n)。我们应该写成O(1 + 1/n)

没有比O(1)小的数 大o符号表示算法的最大复杂度

如果一个算法的运行时间是n³+ n²+ n + 5那么它就是O(n³) 低次在这里根本不重要，因为n ->正无穷，n^2与n^3相比是无关的

同样地，当n -> Inf时，O(1/n)与O(1)相比是不相关的，因此3 + O(1/n)将与O(1)相同，从而使O(1)的计算复杂度最小