在函数式语言中使用大型数据结构时减少垃圾收集时间

Question

在函数式语言中使用大型数据结构时如何减少垃圾收集时间？

（我使用的是 Racket，但这个问题适用于任何带有垃圾收集器的面向功能的语言。）

函数式编程的核心习惯是设计函数来处理数据的副本，并将处理后的数据作为结果返回，而不是从远处改变数据结构。您不必担心额外的复制，因为垃圾收集器会过来并恢复不再使用的内存。

就目前而言，这很棒。但是当我开始编写处理更大数据结构的程序时，我发现更多的总运行时间被垃圾收集占用（如 25-35% 而不是我发现的小型结构的典型 10-15% ）。

这并不奇怪，因为每次函数调用都会复制更多数据，因此需要收集更多垃圾。

但这也使提高速度变得更加困难，因为垃圾收集器占用了更多的运行时间，而这基本上超出了您的控制范围。

显而易见的解决方案是完全避免复制数据。但这会让你回到从远处变异数据，这与函数式习语相矛盾。 （虽然我知道这可以在一定程度上在 Racket 中通过使用装箱值，甚至使用参数来完成。）

除此之外，我想到了三个选择：

1. 设计您的数据结构，使它们对信息进行更紧凑的编码。
2. 与其将整个数据结构传递给函数，不如提取您需要处理的数据子集（当然，这假设分离和重新加入数据子集的成本节省了足够的垃圾收集时间，这是值得的）。
3. 在可能的情况下，将多个函数（通常会将大型数据结构从一个传递到下一个，每次都复制）组合成一个尾递归函数（不会）。

这些是有效的方法吗？还有其他我忽略的吗？

Answer 1

有一些功能性数据结构旨在降低复制成本 - 例如，如果一个函数对树的一个分支进行了变异，那么新树将共享未受影响分支的节点，并且只有变异的分支需要被复制。

Chris Okasaki 的Purely Functional Data Structures 是我所知道的最好的论文，但可能还有我不知道的最新研究（例如，ctrie，我只通过维基百科知道）。

Answer 2

这不是一个完美的答案，但它比我找到的其他资源更切题。这篇名为“Typed Racket 中的函数式数据结构”的论文讨论了在某些情况下比标准列表表现更好的替代函数式数据结构，并给出了包括垃圾收集时间在内的具体计时结果 (HT Greg Hendershott)：

http://www.ccs.neu.edu/racket/pubs/sfp10-kth.pdf

这是实现的代码：

https://github.com/takikawa/tr-pfds

Answer 3

产生大量不必要的垃圾当然是不好的。如果分析器显示您分配了很多内存，并且 GC 成功地恢复了很多内存，那么您应该考虑产生更少的垃圾。这就是您的 (1) 发挥作用的地方：

设计您的数据结构，使它们对信息进行更紧凑的编码。

总的来说，这非常重要。如果 GC 时间影响性能，请尝试使用更紧凑的数据结构。如果 GC 时间不会影响性能，请尝试使用更紧凑的数据结构。紧凑的数据结构提高了 GC 性能和缓存利用率。如果您可以用更少的字节将更多信息塞进 CPU 缓存中，您通常可以获得显着的速度提升。

另一方面，您的 (2) 和 (3) 看起来很可疑，并建议您可能对值在内存中的实际表示方式没有清晰的认识。将结构传递给函数不会通常在典型的函数式语言实现中复制它。也就是说，“取出需要处理的数据子集”是有道理的，因为如果可能不需要其余的数据，您可以更快地将其变成垃圾，这很好。

最后一件事是 25-35% 的 GC 时间可能听起来有点糟糕，但它并没有想象中那么糟糕。我见过的最糟糕的情况是违反了“弱代际假设”。也就是说，当你分配一堆内存时，不会很快变成垃圾。这很糟糕，因为垃圾收集器一直在尝试收集垃圾，跟踪越来越多的非垃圾，但实际上并没有完成太多工作。在这些情况下，我个人看到 GC 时间高达 75% 左右，但如果它可能比这更糟，我不会感到惊讶。