关于减少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这里失去了更多,所以请专家就此问题.

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