编译器优化后如何对Haskell程序进行性能分析？

云上老周

2026-5-20

针对Haskell优化后剩余性能瓶颈的排查方法

嗨，我完全懂你现在的困扰——成本中心分析已经用遍了，而且带 profiling 编译的程序和生产环境（-O2无 profiling）速度差了15倍，这确实让 profiling 的结果参考价值大打折扣。别担心，还有不少适合普通开发者的实用方法，帮你找到那些隐藏的性能热点：

Eventlog + ThreadScope：可视化排查神器
这绝对是普通开发者的福音！它的性能损耗极低，完全能贴近生产环境的运行状态。你只需要在编译时加上-eventlog选项（Stack可以用stack build --ghc-options="-eventlog"），运行程序时附加+RTS -l生成eventlog文件，然后用ThreadScope工具打开这个文件。
它能直观展示线程的运行状态、GC停顿时长、内存分配趋势，甚至能看到函数级别的执行时间分布。很多时候剩余的瓶颈都是GC频繁、线程阻塞，或者某个函数的内存分配量远超预期，这些在ThreadScope里都能一目了然。

手动插入轻量计时探针
如果你已经有几个怀疑的代码块，直接手动加计时逻辑是最直接的方式。用System.Clock（比Data.Time更精准）来计算代码块的执行时间，比如：

import System.Clock

testCriticalCode :: IO ()
testCriticalCode = do
    start <- getTime Monotonic
    -- 你要测试的核心代码逻辑
    processLargeDataset
    end <- getTime Monotonic
    let elapsedMs = toNanoSecs (diffTimeSpec end start) `div` 1000000
    putStrLn $ "核心代码耗时: " ++ show elapsedMs ++ "ms"

记得用条件编译（比如#ifdef BENCHMARK）把这些探针包起来，避免影响生产代码。

内存分配分析：揪出GC背后的元凶
很多时候性能瓶颈不是CPU耗时，而是频繁的GC导致的停顿。你可以用GHC的堆分析工具：编译时加-prof -fprof-auto-top（只分析顶层函数，性能损耗比全量 profiling 小很多），运行程序时加+RTS -h生成堆快照（.hp文件），然后用hp2pdf或者hp2ps转换成可视化的文档。
从这些文档里你能清楚看到哪些函数分配了最多的内存——这些函数往往是隐藏的性能杀手，优化它们的内存使用能大幅提升整体速度。
查看GHC优化后的中间代码
有时候-O2的优化可能没达到你的预期，比如某个高频调用的函数没被inline，或者出现了不必要的装箱/拆箱操作。你可以在编译时加-ddump-simpl选项，GHC会输出优化后的核心语言代码。
不用深入理解所有细节，重点看你关心的函数是否被标记为INLINE，有没有多余的Box/Unbox操作。如果发现函数没被inline，手动加{-# INLINE yourFunc #-}pragma提示GHC优化。
用Criterion做精准基准测试
针对单个函数或模块写基准测试，用criterion库能得到统计意义上可靠的耗时和内存分配数据。在你的Stack/Cabal配置里添加benchmark部分，编写测试用例后运行stack bench，就能得到详细的性能报告。
这种方式能帮你精准对比不同优化方案的效果，明确哪个函数的性能提升空间最大。

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