Rescript编译器在非柯里化模式下丢失的优化问题分析

Rescript编译器在从柯里化模式切换到非柯里化模式时，会出现一些优化丢失的问题。这些问题主要涉及函数内联和临时变量生成等方面，值得深入探讨其背后的原因和解决方案。

函数内联优化丢失

在柯里化模式下，编译器能够直接将getOpt函数优化为对Belt_Option.mapWithDefault的直接引用。这种优化非常高效，因为它完全消除了额外的函数调用开销。然而在非柯里化模式下，编译器生成了一个包装函数，导致额外的调用层级。

这种差异源于柯里化模式和非柯里化模式下函数应用语义的不同。在柯里化模式下，编译器可以安全地假设所有函数都是部分可应用的，这使得直接引用成为可能。而非柯里化模式下，编译器需要更保守地处理函数应用，以确保参数传递的正确性。

临时变量生成问题

另一个明显的优化差异出现在集合操作中。在柯里化模式下，编译器能够直接将Belt_MutableSet.isEmpty和Belt_MutableSet.intersect的操作链式组合在一起。而在非柯里化模式下，编译器生成了一个临时变量d$1来存储中间结果。

这种临时变量的引入虽然保证了正确性，但却带来了额外的内存分配和性能开销。特别值得注意的是，在非柯里化模式下，isEmpty的实现被内联为直接检查data字段是否为undefined，这实际上是一种积极的优化。

Belt集合操作的优化差异

在涉及Belt集合的转换操作中，柯里化模式能够直接将Belt_SetString.fromArray和Belt_SetString.toArray作为函数引用传递。而非柯里化模式则生成了包装函数，增加了额外的函数调用开销。

这种差异反映了柯里化模式和非柯里化模式在函数引用处理上的根本区别。柯里化模式可以更自由地进行函数引用传递，而非柯里化模式则需要确保函数应用的参数传递方式正确。

优化问题的根本原因

这些优化差异的核心在于编译器内部使用的opaqueFullApply和opaque机制。这些机制原本用于防止在非柯里化模式下应用那些假设柯里化语义的转换。通过逐步移除这些限制性转换，可以恢复部分优化机会。

实验表明，完全移除opaque机制在当前状态下是可行的，而移除opaqueFullApply则需要更谨慎的评估，因为它会导致编译器将更多应用视为柯里化应用。一个可能的解决方案是在lambda级别将所有应用转换为App_uncurry形式，这可以解锁大量内联优化机会，尽管可能会引入一些正确性问题。

总结

Rescript编译器在非柯里化模式下丢失的优化问题反映了函数应用语义对编译器优化策略的深远影响。理解这些差异有助于开发者编写更高效的代码，并为编译器优化提供方向。目前这些问题在最新版本中已得到解决，但这一过程揭示了函数式语言编译器中柯里化与非柯里化转换的复杂性和挑战。