Hi, I posted this to elm, but it’s essentially a question about tuning the Haskell program elm make: Possibly OOM with elm make using ` +RTS -N2 -A16m -n4m` - Learn - Elm
Try the Elm builder without any RTS options - at least then we’ll know the Elm builder is working properly with the default RTS configuration.
Then try each RTS option in turn, watching for the problems to reappear.
If no single RTS option is the cause of the problems, then you can start trying combinations of them.
Thanks. As noted in the referenced issue, bounding the allowed memory is working so far.
While diagnosing, I am noticing a lot of time is spent in GC. Are there blog articles or forum posts that discuss understanding the garbage collection stats and configuration options? I don’t expect to get into the elm compiler source, but I can spend some time trying different rts options if I understand their impact on GC performance.
It’s ye ol’ time/space trade-off: bounding the heap size means the RTS will use the GC more often in each process. If there was some way to limit the number of processes the Elm builder starts up (analogous to
-j N or
-l M for
make), then you could then increase the heap.
As for blog articles or forum posts…I would be surprised if there wasn’t. Just be aware that the basic operation of programs like builders or compilers - the formation and use of large structured values in memory (representing the compiled definitions or build dependencies) - constitutes the bulk of the workload: it could be easier to just limit the number of processes so each one can have a larger heap.
P.S: I was having similar problems the last time I was working on GHC 8.6.5
(hence my interest
;-) - the build system originally had 8 Gbyte of RAM; only when it was increased to 16Gbyte did those problems go away.