Skip to content

Reduce long-term memory usage of GHCi

If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using cabal repl, memory usage of GHCi becomes a bit problematic after a few code reloads.

I compared 7.10.3 and 8.0.1 using the following steps:

  1. Start GHCi with cabal repl.
  2. Wait for all modules to load, check memory usage with htop.
  3. Issue find . -name '*.hs' -exec touch {} + in src directory.
  4. Issue :r in GHCi so it reloads all modules.
  5. Repeat (3) and (4) four more times.

Results:

GHC 7.10.3

  • After cabal repl: 874MB
  • After reloading all modules (1st): 1304MB
  • After reloading all modules (2nd): 1763MB
  • After reloading all modules (3rd): 2216MB
  • After reloading all modules (4th): 2672MB
  • After reloading all modules (5th): 3121MB

Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun.

GHC 8.0.1

  • After cabal repl: 1322MB
  • After reloading all modules (1st): 2144MB
  • After reloading all modules (2nd): 2201MB
  • After reloading all modules (3rd): 2208MB
  • After reloading all modules (4th): 2212MB
  • After reloading all modules (5th): 2213MB

Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus.

I presume this change is the result of 6ae616f5 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great).

However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it?

Trac metadata
Trac field Value
Version 8.0.1
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information