如何加快Common Lisp`IF`语句的编译速度?

Mar*_*ein 4 performance if-statement common-lisp runtime-compilation clozure-cl

我有一个生成决策树,并将它们转换成嵌套Common Lisp的系统if与谓词检查,如果一个变量的值的语句>=或者<=一个给定的整数如

(LAMBDA (V1 V2)
  (IF (>= V1 2)
      (IF (<= V1 3)
          (IF (<= V2 3)
              (IF (>= V2 2) 16 (IF (>= V2 1) 6 0))
            (IF (<= V2 4) 10 0))
        (IF (<= V1 4)
            (IF (>= V2 1) (IF (<= V2 3) 6 0) 0)
          0))
    (IF (>= V1 1)
        (IF (>= V2 2) (IF (<= V2 4) 10 0) 0)
      0)))
Run Code Online (Sandbox Code Playgroud)

然后我使用eval编译Lisp代码,生成比解释原始决策树更快的函数.尽管如此,这个编译步骤需要花费相当长的时间:具有5000个嵌套ifs的函数需要花费一分钟来编译(在powerbook上的Clozure Common Lisp中),即使生成if语句需要大约100毫秒.为什么这么简单的结构需要这么长时间?有什么我可以做的大幅加快,一些声明可能吗?我非常感谢您提供的任何指示.

Rai*_*wig 6

调用实际的编译函数的可移植函数COMPILE.

你可以告诉Common Lisp的编译器通过低投入较少的工作optimize质量为speed,space,debugcompilation-speed-这是否有任何影响取决于执行.

Clozure CL编译器通常不是最亮的编译器,但速度相对较快.一般来说,我认为编译器维护者可能会给你更多提示如何加快编译速度.一般来说,我会寻找三个

  1. 告诉编译器做更少的工作:没有类型推断,没有代码优化,没有生成调试信息,没有节省空间,...
  2. 如果有必要告诉编译器它必须推断的东西 - 比如编译器的类型推断,而不是代码生成期间的所有类型.但这意味着您实际上需要从类型声明中获得一些优势,例如增加运行时安全性或代码优化.
  3. 编译器本身可能具有速度惩罚,这可能取决于源代码的大小.例如,如果它是二次的,如果我们将代码大小加倍,则编译时间将增加四.只有编译维护者可能知道在这些情况下该做什么 - 也许他们需要实现更有效的数据结构或类似的....

下一个选项是使用Lisp解释器.它们通常只有非常少的定义时间开销 - 但代码通常在运行时运行得慢得多.在某些问题域中,可能遵循混合方法:编译不经常更改的代码并解释经常更改的代码.