如何强制 ghc 的分析器深入到库中？

Posted 2023-03-06

【中文标题】如何强制 ghc 的分析器深入到库中？

【英文标题】：How to force ghc's profiler to step deeper into the libraries?

【发布时间】：2011-03-04 17:06:34

【问题描述】：

我正在尝试分析我的程序。所以我用-prof 和-auto-all 标志编译它并用-P 运行以获得详细的分析报告：

$ ghc --make -prof -auto-all Test.hs
$ ./Test +RTS -P

这是一份分析报告：

COST CENTRE              MODULE  no.    entries  %time %alloc

  main                   Main   266           1   0.0    0.0
   run                   Main   273       21845  99.3   99.7
    sz                   Main   274       21844   0.0    0.0
   size                  Main   268       21845   0.7    0.3

似乎run 消耗了所有时间和内存。它从各种库中调用了很多函数，我很确定大部分时间都花在其中一个上，但我不知道是哪一个。 如何获得更详细的报告？我希望手动添加大量SCC 注释不是唯一的方法。

更新。现在我通过将库的源代码复制到我的程序目录来“解决”这个问题。这允许 GHC 将它们视为程序的一部分，而不是外部库。

【问题讨论】：

也许 [visual-prof][1] 能以某种方式提供帮助？ [1]:hackage.haskell.org/package/visual-prof

【参考方案1】：

为了让分析器区分库函数，它们必须有成本中心注释。您可以通过两种方式做到这一点：

使用 -p -auto 重新编译感兴趣的库，以便使用 SCC 对库函数进行注释。 在代码中围绕可能耗时的库调用插入 SCC 注释。

【讨论】：

所有库都使用cabal install --enable-library-profiling安装。不是和-p -auto一样吗？

不，和-p一样。 IE。这些库被编译以支持分析调用约定，但没有成本中心注释。我认为 cabal install --enable-executable-profiling 实际上会传递您需要的标志（尽管有名称），但我不确定。

【参考方案2】：

这是一个 gprof 类型的分析器 - pretty weak, for these reasons.

您可以使用GHCi 来查找性能问题，就像查找无限循环by this technique 一样：

6.3 2007 年 11 月 21 日在 glasgow-haskell-users 上的无限循环， pepe 提出以下建议 检测原因无限循环 GHCI。假设有问题的功能 名为loop，取一个 论据：

1.启用标志 -fbreak-on-error（GHCi 中的:set -fbreak-on-error）

2. 使用 :trace (:trace loop 'a') 运行您的表达式

3.当你的程序卡在循环中时按下 Ctrl-C 让调试器在循环中中断

4.使用 :history 和 :back 找出循环的位置和原因。

任何性能问题和无限循环之间的唯一区别是 - 无限循环浪费了 100% 的时间，而性能问题浪费的时间较少。 所以你可能不得不闯入它几次。

【讨论】：

感谢您的链接。这种技术的有用性似乎是由于缺乏良好的分析工具（尤其是 ghc）。