【发布时间】：2017-11-22 21:26:07
【问题描述】：
我认为一切都在标题中，但要提供更多上下文。我们有两个 70 多个包，它们的编译时间完全不同：一个需要的时间是另一个的两倍（不考虑并行化）。我想知道哪些模块花费的时间最多，以便更好地了解造成这种差异的原因。
【问题讨论】：
-
是的，看到了这个问题，但除了一些关于如何使 GHC 更快的一般性建议之外没有其他答案......或者我读得太快了？
【发布时间】：2017-11-22 21:26:07
【问题描述】：
现在，当您使用-ddump-to-file -ddump-timings 构建时，GHC 可以输出每个模块的时序数据。这会导致将扩展名为 .dump-timings 的文件写入构建目录（通常 .stack-work 用于 Stack，dist-newstyle 用于 Cabal）。
我编写了一个工具来查找所有这些文件并将它们可视化：https://github.com/codedownio/time-ghc-modules。
【讨论】：
不确定你是指 70+ packages 还是 70+ modules，但无论如何...
我想不出任何特别简单的方法来做到这一点。您可以尝试准确地确定 GHC 将其消息写入控制台的时间；我不确定那会有多准确。否则，我想您必须弄清楚正确的编译顺序，并手动调用 GHC 一次编译一个模块，并使用操作系统级别的工具来计算每个编译命令需要多长时间。 （也许 GHC 的自动 Makefile 生成功能可以帮助...）
可能在启用分析的情况下编译 GHC 本身，但我认为这在这种情况下没有帮助。 （而且工作量很大。）
FWIW，我也想知道为什么有些模块需要很长时间才能编译，而有些模块几乎是即时编译...
【讨论】：
-
谢谢。我想我有一个基于
-dshow-passes的 emrbyonic 解决方案，它会转储每个模块的一些统计信息（是的，我的意思是 70 个模块，因为我有兴趣知道哪些模块花费的时间最多，对于包来说更容易）。我已经开始编写一些非常简单的工具来从构建和转储统计信息中提取这些信息。