Table of Contents
Please advise us of other “helpful hints” that should go here!
By using them, you are telling GHC that you are willing to suffer longer compilation times for better-quality code.
GHC is surprisingly zippy for normal compilations
Within reason, more memory for heap space means less
garbage collection for GHC, which means less compilation
time. If you use the
you'll get a garbage-collector report. (Again, you can use
+RTS -S -RTS
option to send the GC stats straight to standard
If it says you're using more than 20% of total
time in garbage collecting, then more memory might
help: use the
option. Increasing the default allocation area size used by
the compiler's RTS might also help: use the
+RTS -A<size> -RTS option.
If GHC persists in being a bad memory citizen, please report it as a bug.
As soon as GHC plus its “fellow citizens” (other processes on your machine) start using more than the real memory on your machine, and the machine starts “thrashing,” the party is over. Compile times will be worse than terrible! Use something like the csh-builtin time command to get a report on how many page faults you're getting.
If you don't know what virtual memory, thrashing, and page faults are, or you don't know the memory configuration of your machine, don't try to be clever about memory use: you'll just make your life a misery (and for other people, too, probably).
Because Haskell objects and libraries tend to be large, it can take many real seconds to slurp the bits to/from a remote filesystem.
It would be quite sensible to compile on a fast machine using remotely-mounted disks; then link on a slow machine that had your disks directly mounted.
It's ugly and slow.
We'd rather you reported such behaviour as a bug, so that we can try to correct it.
To figure out which part of the compiler is badly
-v2 option is your friend.