關於減少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這里失去了更多，所以請專家就此問題。

更好的垃​​圾收集有一個相當簡單的前提：創建更少的垃圾，更快地收集它，產生更少的內存分配/解除分配。 你可以做的任何事情都可能導致這三種效果之一值得一試。 測試和基准測試！