我在评论中没有找到太多文档。在这方面有什么好的博客文章或类似的文章吗？
关于评测框架的最佳信息来源可能仍然是Patrick Sansom和Simon Peyton Jones的原始论文。更多细节可以在Sansom的博士论文以及后来添加正式规范的论文中找到。Simon Marlow还在2011年Haskell实施者研讨会上谈到了GHC状态更新的一些最新变化。
成本中心分析背后的思想是用"成本中心"节点注释表达式树，因此例如使用-auto-all，程序将具有如下注释：
fib n = {-# SCC foo #-} (case n of
0 -> 0
1 -> 1
n -> fib (n-1) + fib (n-2))
在运行时，当输入fib时，程序会查看当前的"成本中心堆栈"，并在顶部添加"foo"。一旦评估再次退出SCC注释的范围，这种情况就会逆转。一点魔法可以确保，如果n恰好是一个惰性值，并且程序需要执行其代码，则在必要时会恢复适用于该代码的成本中心。
这种基础设施用于时间和空间分析：
计时器将定期检查成本中心堆栈。每次找到某个成本中心堆栈时，这都算作"勾号"。最后，RTS将根据其滴答声的计数来估计每个成本中心堆栈的时间量，从而为您提供时间配置文件。
每次分配对象时，程序都会将指针保存回该时间点的当前成本中心堆栈。这使垃圾收集器能够按分配站点提供驻留字节数的统计信息。
正如评论中所要求的，关于优化的几句话：由于显而易见的原因，该框架不允许将非恒定成本从一个成本中心转移到另一个，这迫使优化器有时相当悲观。例如，在上面的例子中，当前版本的GHC将不能取消装箱返回值，这意味着每个递归调用都会进行不必要的堆分配。
根据经验，不应指望SCC注释中发生任何代码转换。当有疑问时，最好在调用堆栈中对足够高的函数进行注释，这样就不会对性能关键位进行注释。
您可以找到Jones，Marlow&辛格有用，取决于你想完成什么。它包括在并行环境中分析GHC程序的实践，并包含一些您可能会发现有用的案例研究。