Table of Contents
Please advise us of other “helpful hints” that should go here!
-O
or (especially) -O2
: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
without -O
!
Within reason, more memory for heap space means less
garbage collection for GHC, which means less compilation
time. If you use the -Rghc-timing
option,
you'll get a garbage-collector report. (Again, you can use
the cheap-and-nasty +RTS -S -RTS
option to send the GC stats straight to standard
error.)
If it says you're using more than 20% of total
time in garbage collecting, then more memory might
help: use the
-H<size>
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.
Read
unnecessarily: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
behaved, the
-v2
option is your friend.