Haskell中基于where子句的递归函数内联优化机制与闭包开销探究

首先说清楚最核心的认知偏差：两个版本在闭包传递的绝对开销上，其实没有本质差别。
预优化版本里每次递归调用func f xs，看起来是显式把f当参数传进递归调用点，实际GHC在编译阶段本来就会给这个自递归函数生成一个闭包环境，把f作为自由变量绑定在环境里；优化版本里的内层loop，同样是靠闭包捕获拿到f的值。单从递归执行的闭包大小、创建次数来看，俩版本在没有触发深度内联的场景下几乎完全一致——amalloy提出的疑问在这个场景下是完全成立的。

那这个写法调整的优化价值到底在哪？核心是绕开了GHC对自递归函数的内联限制：

• 预优化版本里的func是标准的直接自递归函数，按照GHC的编译规则，这类函数上的INLINE编译指示会被直接忽略，因为自递归的调用结构本身存在循环依赖，没法在不破坏递归逻辑的前提下把整个函数展开到调用点。这也就意味着，哪怕你给func开了最高级别的优化，只要它是自递归结构，GHC就不会把它内联到实际调用它的位置，f作为函数的显式参数，会永远跟着每次递归调用走，没有机会被消掉。
• 优化版本把结构拆成了两层：外层的func本身完全不是递归的，它在接收参数f之后直接返回内层loop的执行结果，属于典型的可内联的非递归函数；真正的自递归逻辑全部放在了where子句定义的loop上，而且loop的递归调用里已经不再显式传递f——因为f已经是它闭包里捕获的固定变量了。

这个结构为啥对内联友好？
当你在别处调用func (*2) [1,2,3]的时候，GHC可以毫无阻碍地把外层非递归的func整个展开到这个调用点上，把f = (*2)的绑定直接替换进loop的定义里。这一步做完之后，原来loop为了捕获f创建的闭包就直接消失了：因为f已经被替换成了具体的(*2)，loop变成了完全没有自由变量的本地递归函数，根本不需要再带着f的引用跑完整条递归链路。
对比预优化版本的func，因为它是自递归的、没法被整体内联到调用点，哪怕你传的是具体的(*2)，f依然是作为独立参数在每次递归调用里被搬运，永远不会被编译器消掉——这才是两个版本的性能差距的真正来源，和闭包创建的数量没关系。

关于-O2参数的作用范围：
-O2默认开启的优化流水线，已经包含了尾递归优化、严格性分析、普通函数内联的能力，但它不会主动帮你重构自递归函数的参数结构——也就是说，如果你写的是预优化版本的代码，哪怕拉满优化等级，GHC也只会在原有的递归结构上做微调，不会主动把f从递归参数里挪到闭包、再通过内联消掉闭包开销。这种源码层面的结构拆分，是需要手动调整的，编译器不会自动做这类重构。

这种写法和流融合技术也是适配的：
流融合的核心要求是，流处理函数必须能被内联到调用点，才能和前后相邻的流操作融合，跳过中间列表的生成。你用where子句包内层循环的结构，刚好给GHC的融合pass留了足够的展开空间——外层可内联的结构展开之后，整个递归函数就能和相邻的map、filter操作融合成单趟遍历的逻辑。如果是预优化版本的自递归结构，因为没法被整体内联，根本参与不到融合流程里。

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