有关剖析框架的最佳信息来源可能仍然是Patrick Sansom和Simon Peyton Jones 的原始论文.其他细节可以在桑塞姆的发现博士论文,以及在后文将正式规范.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注解.如果有疑问,最好在调用堆栈中注释一个足够高的函数,因此性能关键位根本不会被注释.