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

Question

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

之前

分析当前版本编译器的正常运行情况如下:

  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

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

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

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