关于减少GHC中GC时间的一般建议

Question

当GHC编译的程序花费大量时间进行垃圾收集时，是否有任何通用规则可以发现原因？什么通常被认为太多了？例如，一般来说，60％的生产率是否可以接受，或者是否表明代码可能存在问题？

Answer 1

这是一个快速且非常不完整的列表：

1. 测试和基准。 haskell的一个弱点是难以预测时间和空间成本。如果你没有测试数据，你什么都没有。
2. 使用更好的算法。这听起来太简单了，但是优化效率低下的算法就好像用金牌敲打一样。
3. 策略性地使一些数据更严格。 测试和基准测试！目标是存储物理上较小的WHNF值而不是产生它的thunk，从而在最有效的第一次传递中清理更多的垃圾。寻找产生简单数据的复杂函数。
4. 策略性地使一些数据不那么严格。 测试和基准测试！目标是延迟生成大量数据，直到它被使用和丢弃之前，从而在最有效的第一次通过中清理更多垃圾。寻找产生大量复杂数据的简单函数。另见comonads。
5. 策略性地使用数组和未装箱的类型，特别是参见＃2。关于ST monad。 测试和基准测试！所有这些都将更多原始数据放入更小巧的内存中。收集的垃圾更少。
6. 摆弄RTS设置（特定ghc）。 测试和基准测试！目标是将“阻抗匹配”GC与程序的内存需求相匹配。我在1-5这里失去了更多，所以请问专家。

更好的垃圾收集有一个相当简单的前提：创建更少的垃圾，更快地收集它，产生更少的内存分配/解除分配。你可以做的任何事情都可能导致这三种效果之一值得一试。 测试和基准测试！