解释 GHC 堆配置文件中的悬崖边缘

Question

我需要一些帮助来理解一些 GHC 堆配置文件。我正在为语法框架语言的现有编译器开发一种新的输出格式。

前

分析当前版本编译器的正常运行如下所示：

  13,347,660,488 bytes allocated in the heap
 213,062,924,208 bytes copied during GC
     740,585,528 bytes maximum residency (567 sample(s))
       4,844,112 bytes maximum slop
            1438 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     12312 colls,     0 par    1.321s   1.382s     0.0001s    0.0025s
  Gen  1       567 colls,     0 par   206.442s  208.534s     0.3678s    0.8388s

  INIT    time    0.001s  (  0.005s elapsed)
  MUT     time   68.757s  ( 68.986s elapsed)
  GC      time  109.557s  (111.086s elapsed)
  RP      time    0.000s  (  0.000s elapsed)
  PROF    time   98.206s  ( 98.830s elapsed)
  EXIT    time    0.000s  (  0.001s elapsed)
  Total   time  276.521s  (278.908s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    194,128,534 bytes per MUT second

  Productivity  60.4% of total user, 60.2% of total elapsed

后

通过我所做的更改，它现在看起来像这样：

  15,996,529,552 bytes allocated in the heap
 216,727,207,600 bytes copied during GC
     889,791,520 bytes maximum residency (578 sample(s))
       5,417,952 bytes maximum slop
            1741 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     14915 colls,     0 par    1.641s   1.721s     0.0001s    0.0014s
  Gen  1       578 colls,     0 par   226.744s  230.323s     0.3985s    1.1982s

  INIT    time    0.001s  (  0.005s elapsed)
  MUT     time   70.046s  ( 70.242s elapsed)
  GC      time  120.183s  (122.695s elapsed)
  RP      time    0.000s  (  0.000s elapsed)
  PROF    time  108.201s  (109.349s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time  298.431s  (302.291s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    228,370,682 bytes per MUT second

  Productivity  59.7% of total user, 59.4% of total elapsed

所以这个新版本比以前的版本使用更多的时间和内存，我的目标是尽可能地减少这些。

• 两个图的第一部分看起来相同，编译器的这个阶段（即读取二进制文件）没有被触及，因此我希望它看起来相同。
• 之后，图表就大不相同了。我觉得图 #2 中巨大的悬崖边缘在告诉我一些事情，但我不太清楚是什么。
• 图#2（24956）后半部分的蓝色区域是我新添加的代码。由于我没有积极优化该代码，我希望那里有改进的余地。但是这些不同的图表是否给出了关于懒惰/严格或进一步调查的任何提示？

Answer 1

该轮廓形状表明一个大的值图表突然变得无法访问。那可能是意外产生的一堆重击声。或者它可能是某种经过评估和正确使用的中间结构，但最终不再需要和发布。

但是你可以肯定地说，这不是大量未经评估的 thunk 被建立起来然后在评估过程中遍历的结果。它的形状类似于您的第一个图表 - 分配时呈上升趋势，然后在评估时呈下降趋势。

悬崖说某件大事突然变得遥不可及。至于什么？谁知道。我们需要看代码。