Haskell编译器性能分析：runVehicle匿名lambda耗时占比异常求解

解答 #

核心误解：GHC默认Profiling是包含式统计

你对cost centre的认知有误——GHC默认用-p生成的时间/分配报告是**包含式（inclusive）**的：它会将该cost centre管辖范围内所有子函数调用的耗时与内存分配全部计入，而非仅统计lambda自身的分支判断逻辑。runVehicle.\对应的匿名lambda是整个编译/检查流程的顶层执行闭包，typeCheck/compile等核心逻辑都在它的执行上下文内，这些子调用的开销自然会被归到该cost centre下。

额外拉高占比的原因

1. withLogger的初始化开销被关联到Lambda
   withLogger作为资源管理函数，必然会在执行传入的lambda前完成日志系统的初始化工作（比如配置加载、句柄创建、缓冲区分配等）。由于Haskell闭包的捕获特性，这些初始化操作的开销会被GHC profiling器关联到传入的lambda cost centre上，进一步推高了它的占比。

2. 模式匹配的隐性开销
   虽然代码看起来只是简单的case分支，但Haskell的模式匹配涉及隐性操作：

   • 对modeOptions和mode构造器的拆箱与类型检查
   • 错误提示字符串常量的内存分配
   • fatalError的异常机制预初始化（即使未触发，也可能产生少量开销）
     这些操作的执行时间和内存分配都会被计入该lambda的统计结果。

验证与定位建议

• 生成独占式报告：使用+RTS -P替代-p，该报告仅统计cost centre自身的执行时间，排除子调用开销，能直观看到lambda分支逻辑的真实占比。
• 堆火焰图分析：用+RTS -hy生成堆火焰图，定位runVehicle.\下具体的内存分配来源，判断是初始化开销还是子调用导致的分配。
• 手动标记cost centre：给typeCheck/compile等核心函数添加{-# SCC "typeCheck" #-}编译指令，强制将它们的开销单独统计，验证是否从runVehicle.\中拆分出来。

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