Generic advice on reducing GC time in GHC

Question

Are there any generic rules to follow in order to discover the cause when a GHC-compiled program spends to much time doing garbage collection? And what would be generally considered too much? For example, in general, is 60% productivity acceptable or is it an indication that something is likely wrong with the code?

Answer 1

Here's a quick and very incomplete list:

1. Test and benchmark. One of haskell's few weaknesses is the difficulty in predicting time and space costs. If you don't have test data you've got nothing.
2. Use better algorithms. This sounds too simple, but optimizing inefficient algorithms is like rapping s**t in gold.
3. Strategically make some data more strict. Test and Benchmark! The goal is to store the physically smaller WHNF value rather then the thunk that produces it, thereby cleaning up more garbage in the most efficient first pass. look for complicated functions that produce simple data.
4. Strategically make some data less strict. Test and Benchmark! The goal is delay production of a large amount of data until just before it is used and discarded, thereby cleaning up more garbage in the most efficient first pass. Look for simple functions that produce large complex data. See also comonads.
5. Strategically make use of arrays and unboxed types, in particular see #2. with regard to the ST monad. Test and Benchmark! All of these fit more raw data into smaller more compact memory. There is less garbage to collect.
6. Fiddle with the RTS settings (ghc specific). Test and Benchmark! The goal is to "impedence match" the GC with the memory needs of your program. I get even more lost here then in 1-5 so ask the experts on this one.

Better garbage collection has a fairly simple premise: Create less garbage, collect it sooner, produce fewer memory allocations/deallocations. Any thing you can do that might result in one of these three effects is worth a shot. Test and Benchmark!