当GHC编译程序花费大量时间进行垃圾收集时，是否有任何通用规则可用来发现原因？那通常被认为太多了？例如，通常来说60％的生产率是可以接受的，还是表明代码可能有问题？
这是一个快速且非常不完整的列表:
测试和基准。 haskell的几个弱点之一是难以预测时间和空间成本。如果没有测试数据，您将一无所有。 使用更好的算法。这听起来太简单了，但是优化效率低下的算法就像敲诈黄金。 从策略上使一些数据更加严格。 测试和基准测试! 目标是存储物理上较小的WHNF值，而不是存储产生该值的thunk，从而以最有效的第一遍清除更多垃圾。寻找产生简单数据的复杂函数。 从策略上使一些数据不太严格。 测试和基准测试! 目标是将大量数据的生成延迟到使用和丢弃之前，从而在最有效的第一遍中清理更多垃圾。寻找产生大量复杂数据的简单函数。另请参见comonads。 从策略上利用数组和未装箱的类型，特别是请参阅＃2。关于ST monad。 测试和基准测试! 所有这些都将更多原始数据放入更小巧，更紧凑的内存中。收集的垃圾更少。 带有RTS设置的小提琴(特定于ghc)。 测试和基准测试! 目标是使GC与程序的内存需求“阻抗匹配”。在1-5中，我在这里迷失了更多，因此向专家咨询这一问题。
更好的垃圾回收具有一个相当简单的前提:创建更少的垃圾，更快地收集垃圾，产生更少的内存分配/释放。您可能会导致这三种效果之一的任何操作都值得一试。 测试和基准测试!