SWI Prolog 使用的检查优化会发生什么情况？

去引用SICStus Prolog 手册 https://sicstus.sics.se/sicstus/docs/3.12.9/html/sicstus/Occur.html:

逻辑编程背后的通常数学理论禁止 创建循环项，规定发生检查应该是 每次将变量与术语统一时完成。不幸的是，一个 发生检查会非常昂贵使 Prolog 变得不切实际作为 一种编程语言。

然而，我跑了这些基准 https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/bench（Prolog 的），并且在 SWI Prolog 中发生检查 (OC) 开启和关闭之间存在相当小的差异（小于 20%）：

超频关闭：:- set_prolog_flag(occurs_check, false). in .swiplrc（重新启动）

?- run_interleaved(10).
% 768,486,984 inferences, 91.483 CPU in 91.483 seconds (100% CPU, 8400298 Lips)
true.

?- run(1).
'Program'            Time     GC
================================
boyer               0.453  0.059
browse              0.395  0.000
chat_parser         0.693  0.000
crypt               0.481  0.000
fast_mu             0.628  0.000
flatten             0.584  0.000
meta_qsort          0.457  0.000
mu                  0.523  0.000
nreverse            0.406  0.000
poly_10             0.512  0.000
prover              0.625  0.000
qsort               0.574  0.000
queens_8            0.473  0.000
query               0.494  0.000
reducer             0.595  0.000
sendmore            0.619  0.000
simple_analyzer     0.620  0.000
tak                 0.486  0.000
zebra               0.529  0.000
           average  0.534  0.003
true.

OC 已开启：:- set_prolog_flag(occurs_check, true). in .swiplrc（重新启动）

?- run_interleaved(10).
% 853,189,814 inferences, 105.545 CPU in 105.580 seconds (100% CPU, 8083669 Lips)
true.

?- run(1).
'Program'            Time     GC
================================
boyer               0.572  0.060
browse              0.618  0.000
chat_parser         0.753  0.000
crypt               0.480  0.000
fast_mu             0.684  0.000
flatten             0.767  0.000
meta_qsort          0.659  0.000
mu                  0.607  0.000
nreverse            0.547  0.000
poly_10             0.541  0.000
prover              0.705  0.000
qsort               0.660  0.000
queens_8            0.491  0.000
query               0.492  0.000
reducer             0.867  0.000
sendmore            0.629  0.000
simple_analyzer     0.757  0.000
tak                 0.550  0.000
zebra               0.663  0.000
           average  0.634  0.003
true.

这些基准测试不能代表现实世界的使用情况吗？ （我记得在某处读到，它们被专门选择为“相当有代表性”）SWI Prolog 是否实施了一些 SICStus 人员不知道的优化技巧，从而使 OC 的成本较小？如果有，它们是否已出版？ （我找到了很多90年代关于这个问题的论文，但我不知道它们是否是最先进的）

主要优化使局部变量的统一成为常量操作。

Many 抽象机器 https://stackoverflow.com/a/4504325/772868像 PLM、ZIP、WAM、VAM 一样，为逻辑变量提供了一种特殊情况，这些逻辑变量不能是某些结构的子项（称为局部变量）。与这些变量的统一根本不需要任何发生检查，因此可以是常量。 以这种方式，大术语可以被“传回”，而不需要额外的发生检查。

如果没有这种优化，语法处理（用于解析给定列表）的开销将是令牌数量的二次方。每次交回“输入列表”时（因此，从图形上讲，每次在语法体中的非终结符后面交叉逗号时），都需要扫描剩余的输入列表以查找该局部变量的出现。 （它比字符数量的二次方要好，因为正则表达式大多是尾递归编码的）。

此次优化已推出2007 年 5.6.39 http://www.complang.tuwien.ac.at/ulrich/swi-prolog/#110。 令人惊讶的是，即使在像 tak 这样根本没有建造任何结构的情况下，您的测量结果也显示了开销。据我所知，SWI 5.6.39 中的事件检查统一运行速度比理性树统一（对于简单情况）要快一点，因为（当时）不需要额外的设置。

仍有足够的空间进行许多进一步的发生检查优化。但只有当人们确实使用此功能时，这些才会发生。至于SWI，过去13年并没有发生太多事情。

但想一想：第一个 Prolog，称为 Prolog 0，默认情况下确实支持发生检查。但从 Prolog I（“马赛 Prolog”）开始，只有借口（例如您引用的那些）。至少，该标准并没有通过仅定义默认情况来排除发生检查统一NSTO https://stackoverflow.com/q/30539312/772868处决和要求unify_with_occurs_check/2 and acyclic_term/1 http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#acyclic_term。现在，序言就像 https://en.wikipedia.org/wiki/Occurs_check#Sound_UnificationSWI、Tau 和 Scryer 通过标志选择性地提供它。

同一方向的进一步优化是 Joachim Beer 的 NEW_UNBOUND 标记，它避免了额外发生的某些堆变量的检查，但代价是更复杂的方案。看 重新审视发生检查问题。 JLP 5(3) 1988。和 LNCS 404。