performance - GHC 的垃圾收集 RTS 选项

Question

我有一个 Haskell 程序，它处理一个文本文件并构建一个 Map (包含数百万个元素)。整个过程可以持续2-3分钟。我发现调整 -H 和 -A 选项会对运行时间产生很大影响。

有documentation关于 RTS 的这个功能，但这对我来说很难读，因为我不知道 GC 理论中的算法和术语。我正在寻找技术性较低的解释，最好是针对 Haskell/GHC 的。是否有任何关于为这些选项选择合理值的引用？

编辑:这就是代码，它为给定的单词列表构建一个字典树。

buildTrie :: [B.ByteString] -> MyDFA 
buildTrie l = fst3 $ foldl' step (emptyDFA, B.empty, 1) $ sort $ map B.reverse l where
    step :: (MyDFA , B.ByteString, Int) -> B.ByteString -> (MyDFA , B.ByteString, Int)
    step (dfa, lastWord, newIndex) newWord = (insertNewStates, newWord, newIndex + B.length newSuffix) where            
        (pref, lastSuffix, newSuffix) = splitPrefix lastWord newWord
        branchPoint = transStar dfa pref

        --new state labels for the newSuffix path
        newStates = [newIndex .. newIndex + B.length newSuffix - 1]
        --insert newStates
        insertNewStates = (foldl' (flip insertTransition) dfa $ zip3 (branchPoint:init newStates) (B.unpack newSuffix) newStates)

Answer 1

一般来说，垃圾收集是空间/时间的权衡。给GC更多的空间，就会花费更少的时间。还有(许多)其他因素在发挥作用，特别是缓存，但空间/时间权衡是最重要的一个。

这种权衡是这样的:程序分配内存直到达到某个限制(由 GC 的自动调整参数决定，或通过 RTS 选项显式决定)。当达到限制时，GC 会跟踪程序当前正在使用的所有数据，并回收不再需要的数据所使用的所有内存。此过程延迟的时间越长，同时无法访问(“死亡”)的数据就越多，因此 GC 会避免跟踪该数据。延迟 GC 的唯一方法是提供更多内存可供分配；因此更多的内存等于更少的 GC，等于更低的 GC 开销。粗略地说，GHC 的 -H 选项允许您设置 GC 使用的内存量的下限，因此可以降低 GC 开销。

GHC 使用分代GC，这是对基本方案的优化，其中堆被分为两代或更多代。对象被分配到“年轻”一代，而存活足够长的对象被提升到“老”一代(在第二代设置中)。年轻代的收集比老一代更频繁，其想法是“大多数对象在年轻时死亡”，因此年轻代收集很便宜(它们不跟踪太多数据)，但它们回收大量内存。粗略地说，-A 选项设置年轻代的大小 - 即年轻代被收集之前将分配的内存量。

-A 的默认值为 512k:最好让年轻代小于 L2 缓存大小，如果超过 L2 缓存大小，性能通常会下降。但相反的方向是 GC 空间/时间权衡:使用非常大的年轻代大小可能会通过减少 GC 必须完成的工作量来抵消缓存带来的好处。这种情况并不总是发生，它取决于应用程序的动态，这使得 GC 很难自动调整自身。 -H 选项还会增加年轻代的大小，因此也会对缓存使用产生不利影响。

底线是:尝试一下这些选项，看看什么有效。如果您有足够的空闲内存，您很可能可以通过使用 -A 或 -H 来提高性能，但不一定。