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 -Sstderr -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.

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.