Common Lisp 无&rest高效处理supplied-p参数的非分配实现

核心问题拆解 #

你当前实现的所有堆内存分配，全部来自运行时为apply构造临时参数列表的操作：每次执行(list b)都会生成一个cons单元，100万次循环累积下来的分配量，刚好和测试里显示的15.9MB consed数值完全匹配。
我们的实现需要同时满足三个硬约束：

• 调用bar时完整保留每个可选参数的supplied-p标记值，让bar内部的bp和foo内部的bp值完全一致
• 不使用&rest吞掉所有参数，保证Emacs eldoc-mode可以正常解析函数签名，显示每个参数的提示
• 全程不产生不必要的堆内存分配，同时兼容多&optional、&key参数的通用场景

零分配的通用实现思路 #

核心是把原来运行时动态拼参数列表的逻辑，完全提前到编译期静态完成，从根源上消除临时列表构造：

• 包装函数foo的lambda列表和bar保持完全一致的参数签名，所有形参明明白白写在defun的参数列表里——这种写法eldoc可以正常解析，根本不会出现参数提示缺失的问题
• 针对每个可选/关键字参数，在宏展开阶段遍历所有supplied-p的可能组合，生成对应的静态函数调用分支：
  • 当某个参数的supplied-p为nil时，生成的调用里不传递这个参数值
  • 当某个参数的supplied-p为t时，生成的调用里直接把对应的实参传进去
• 所有生成分支都是无列表构造的直接函数调用，运行时不会产生任何临时对象，自然没有cons开销

单参数场景的最简验证 #

针对你当前只有一个可选参数b的测试场景，根本不需要宏生成，直接手写条件分支就可以实现零分配：

(defun foo (a &optional (b nil bp))
  (declare (optimize speed))
  ;; 两个静态分支，完全没有列表构造
  (if bp
      (bar a b)
      (bar a)))

把原来的apply + nconc替换成上面的分支后，重新跑100万次循环的测试，cons数会直接降到0，因为整个过程没有任何堆上的临时对象生成。原来的cons开销完全是多余的。

多参数场景的兼容处理 #

当存在多个&optional或者&key参数时，宏展开会自动覆盖所有supplied-p的组合：

• 比如存在3个带supplied-p的可选参数时，总共生成8种调用分支，每个分支对应一组supplied-p的取值，分支内部都是直接的静态调用
• 编译器在optimize speed的配置下，会自动把这些分支优化到最优，甚至把bar内联到foo的函数体里，连函数调用的开销都能消掉，整体性能远好于原来的apply方案
• 因为整个过程没有用到&rest吞参数，eldoc依然可以正常识别所有显式声明的形参，正确显示每个参数的提示信息

非可移植的极端优化方案 #

如果遇到可选/关键字参数数量极多，宏展开生成的分支导致代码过度膨胀的场景，可以依赖具体Common Lisp实现的内部调用约定做优化：

• 比如SBCL的&optional参数的supplied-p值，是通过实际调用时传入的参数个数和函数定义的必填参数个数的差值直接计算的，不需要根据传入值判断
• 这种方式不需要生成大量分支，也完全零分配，但属于实现内部的非可移植接口，一旦更换Lisp实现就会失效，仅在性能极端敏感的场景下可以考虑使用

注意：所有方案的核心都是规避“运行时为apply构造参数列表”这个操作，只要把动态拼参数的逻辑换成静态确定的调用形式，就能彻底消除不必要的内存分配，同时完全满足eldoc的兼容性要求。

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