为何函数设计微小改动会导致Criterion基准测试结果大幅差异？

原因来自GHC的多态特化、内联优化的触发逻辑差异 #

• 多态参数阻碍特化
  第一种实现的两个生成函数都是多态定义：regularVectorGenerator :: (Int -> t) -> V.Vector t、unboxedVectorGenerator :: Unbox t => (Int -> t) -> UB.Vector t。GHC默认不会自动跨模块特化带多态参数/类型类约束的顶层函数，就算你实际传入的(+2137)返回Int类型，编译器也没法把生成逻辑实例化为Int特化版本，运行时需要额外承担类型类字典分派、高阶函数调用的开销，也没法对元素计算做常量折叠、循环优化。
• 高阶参数的优化优先级更低
  GHC对数值参数的优化处理远比高阶函数参数激进。第二种实现把计算逻辑(+2137)硬编码在生成函数内部，仅传入数值类型的长度参数，整个生成函数的类型完全固定，没有多态变量。编译器可以直接把(+2137)内联到V.generate/UB.generate的循环逻辑中，甚至可以做循环展开、向量化、预分配优化，unboxed向量的场景下可以完全优化成原生数组的批量填充，没有任何额外开销。
• 如果你想让第一种实现达到第二种的性能，可以给两个生成函数添加强制内联的编译指示：

{-# INLINE regularVectorGenerator #-}
regularVectorGenerator :: (Int -> t) -> V.Vector t
regularVectorGenerator = V.generate 99999

{-# INLINE unboxedVectorGenerator #-}
unboxedVectorGenerator :: Unbox t => (Int -> t) -> UB.Vector t
unboxedVectorGenerator = UB.generate 99999

强制内联后GHC会在调用点特化出Int类型的实现，性能和第二种基本一致。

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