下面，我只考虑纯Prolog 程序。这意味着我不是在谈论离开逻辑领域去做一些在 Prolog 中无法观察到的副作用和操作系统调用。
Prolog 程序的运行时间成本有一个众所周知的抽象度量：逻辑推理的数量。通过“抽象”，我的意思是这个措施独立于任何特定的 Prolog 实现和实际的具体硬件。从某种意义上说，它是一种度量，它为我们提供了一些关于执行程序所需时间的信息。我们甚至可以通过说明 Prolog 系统每秒的推理次数来指定 Prolog 系统的性能 （LIPS），这被广泛使用，以至于人们可以将其称为系统性能的传统衡量标准。传统上，这个数字是通过特定的基准来衡量的，但是“推理次数”的一般概念当然也扩展到其他更复杂的 Prolog 程序。
但是，据我了解，这种特殊的（我敢说：具体的）抽象措施并不能说明以下重要意义的全部真相：
对于任何给定的 Prolog 目标 G，让我们用t (G) 表示：T →R 是 G 在特定硬件上给定 Prolog 系统上的实际执行时间，即从 Herbrand 项到实数的函数。让我们称量度为 α : T →R真实的， 当且仅当 t (G) ≈ α(G) 对于所有 G，在某种意义上，这些值的差异由一个以常数为界的因子对于所有目标 G 和所有“现实”类型的硬件（我必须稍微低估最后一点，但为了简单起见，我在这里假设相同的 Prolog 实现在“典型”硬件上以大致相同的方式执行。我知道这实际上并非如此，并且相同的实现可以在不同类型的硬件上表现出截然不同的特征。如果是这样，请将定义限制为实现“大致”相同的硬件类型的子集。）
据我所知，逻辑推理的数量通常不是 Prolog 目标实际执行时间的真实衡量标准，特别是因为执行统一所需的时间不是由它衡量的。可以构建这种测量与实际执行时间之间的差异不再受常数限制的情况。
因此，我的问题是： Prolog 目标的运行时间是否有真实的抽象度量？如果它一般不存在，请指定一个有意义的 Prolog 程序子集，其中可以定义这样的度量。例如，通过限制可能发生的统一类型。
这个问题具有很高的实际意义，例如在使用 Prolog 实现智能合约时：在这种情况下，您希望抽象地测量运行 Prolog 程序需要多长时间，即使您的程序运行在需要达成一致的不同机器上关于运行它所花费的时间，但您希望保留未来改进具体实现技术的可能性。因此，该措施应该只取决于实际给定的程序，而不是实现的任何具体特征，例如访问的存储单元的数量。