Scheme递归中创建闭包过程的性能影响及规范行为问询

Scheme官方标准（从R5RS到最新的R7RS）仅明确强制要求实现必须支持适当的尾递归消除，也就是你提到的尾调用优化，除此之外的所有编译/运行时优化都属于实现的自由选择，没有任何强制约束。

你提到的重复(rember-f test?)调用的冗余消除，属于公共子表达式消除+不可变绑定值传播的组合优化，规范完全没有做任何约束，行为完全取决于具体实现的优化策略。

不同Scheme实现的实际表现差异 #

• 无优化的解释运行模式（比如Guile默认REPL、Racket无优化调试模式）：通常不会做这类优化，每次递归都会重新调用rember-f生成新的闭包，处理长列表时会产生大量不必要的闭包分配开销，运行效率明显低于你修改后的版本。
• 开启优化的编译运行模式（比如Guile加-O2参数编译、Chez Scheme默认编译、Racket使用raco optimize编译、Gambit Scheme）：几乎都会识别到顶层的rember-f绑定不可变、外层作用域的test?参数也不可变，会把(rember-f test?)的结果提前提取复用，不会重复生成闭包，最终生成的可执行代码和你修改后的retfun版本性能没有明显差异。

写法建议 #

你修改后的版本是更稳妥的通用写法，完全不依赖实现的优化能力就能达到最优性能，同时递归调用的指向更清晰，可读性也更好，也是《The Little Schemer》后续介绍高阶函数递归时的推荐写法。

内容的提问来源于stack exchange，提问作者Poisson Aerohead