当GHC编译的程序花费大量时间进行垃圾收集时，是否有任何通用规则可以用来发现原因？什么通常会被认为太多？例如，一般来说，60%的生产率是可以接受的吗？还是这表明代码可能有问题？
这里有一个快速且非常不完整的列表：
- 测试和基准测试。哈斯克尔为数不多的弱点之一是难以预测时间和空间成本。如果你没有测试数据，你什么都没有
- 使用更好的算法。这听起来太简单了，但优化低效的算法就像在黄金中敲击s**t
- 从策略上使某些数据更加严格测试和基准测试目标是存储物理上较小的WHNF值，而不是产生它的thunk，从而在最有效的第一次传递中清除更多垃圾。寻找产生简单数据的复杂函数
- 从策略上降低某些数据的严格性测试和基准测试目标是将大量数据的生成延迟到使用和丢弃之前，从而在最高效的第一次传递中清除更多垃圾。寻找生成大型复杂数据的简单函数。另请参见comonads
- 战略性地利用数组和未装箱的类型，特别是参见#2。关于ST monad测试和基准测试所有这些都可以将更多的原始数据放入更小、更紧凑的内存中。要收集的垃圾少了
- 摆弄RTS设置（特定于ghc）测试和基准测试目标是将GC与程序的内存需求进行"阻抗匹配"。我在这里比1-5更迷失了方向，所以请专家们谈谈这一点
更好的垃圾收集有一个相当简单的前提：创建更少的垃圾，更快地收集垃圾，产生更少的内存分配/释放。你能做的任何可能导致这三种效果之一的事情都值得一试测试和基准测试