这个问题并不像在某些人看来那么愚蠢。至少在理论上，当我们采用大 O符号的数学定义时，诸如 O (1/ n )之类的东西是完全合理的：

现在您可以轻松地将 g ( x ) 替换为 1/ x ——很明显，上述定义仍然适用于某些 f 。

出于估计渐近运行时间增长的目的，这是不太可行的——一个有意义的算法不能随着输入的增长而变得更快。当然，您可以构建任意算法来实现这一点，例如以下算法：

def get_faster(list):
    how_long = (1 / len(list)) * 100000
    sleep(how_long)

显然，随着输入大小的增长，这个函数花费的时间更少——至少直到某个限制，由硬件强制执行（数字的精度、sleep可以等待的最短时间、处理参数的时间等）：这个限制将是一个恒定的下限，因此实际上上述函数
仍然 具有运行时间 O (1)。

但实际上有 一些 现实世界的算法，当输入大小增加时，运行时间会减少（至少部分减少）。请注意，这些算法 不会 表现出低于 O (1)
的运行时行为。不过，它们很有趣。例如，以Horspool的非常简单的文本搜索算法为例。在这里，预期的运行时间将随着搜索模式长度的增加而减少（但增加干草堆的长度将再次增加运行时间）。