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 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⟩ (see -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 (see -A ⟨size⟩).
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.
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.
The key tool to use in making your Haskell program run faster are GHC’s profiling facilities, described separately in Profiling. There is no substitute for finding where your program’s time/space is really going, as opposed to where you imagine it is going.
Another point to bear in mind: By far the best way to improve a program’s performance dramatically is to use better algorithms. Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below.
Another extremely efficient way to make your program snappy is to use library code that has been Seriously Tuned By Someone Else. You might be able to write a better quicksort than the one in Data.List, but it will take you much longer than typing import Data.List.
Please report any overly-slow GHC-compiled programs. Since GHC doesn’t have any credible competition in the performance department these days it’s hard to say what overly-slow means, so just use your judgement! Of course, if a GHC compiled program runs slower than the same program compiled with NHC or Hugs, then it’s definitely a bug.
This is the most basic way to make your program go faster. Compilation time will be slower, especially with -O2.
At present, -O2 is nearly indistinguishable from -O.
Signatures are the basic trick; putting them on exported, top-level functions is good software-engineering practice, anyway. (Tip: using the -Wmissing-signatures option can help enforce good signature-practice).
The automatic specialisation of overloaded functions (with -O) should take care of overloaded local and/or unexported functions.
Specialize the overloading on key functions in your program. See SPECIALIZE pragma and SPECIALIZE instance pragma.
A low-tech way: grep (search) your interface files for overloaded type signatures. You can view interface files using the --show-iface ⟨file⟩ option (see Other options related to interface files).
$ ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
And, among other things, lazy pattern-matching is your enemy.
(If you don’t know what a “strict function” is, please consult a functional-programming textbook. A sentence or two of explanation here probably would not do much good.)
Consider these two code fragments:
f (Wibble x y) = ... # strict
f arg = let { (Wibble x y) = arg } in ... # lazy
The former will result in far better code.
A less contrived example shows the use of cases instead of lets to get stricter code (a good thing):
f (Wibble x y) # beautiful but slow
= let
(a1, b1, c1) = unpackFoo x
(a2, b2, c2) = unpackFoo y
in ...
f (Wibble x y) # ugly, and proud of it
= case (unpackFoo x) of { (a1, b1, c1) ->
case (unpackFoo y) of { (a2, b2, c2) ->
...
}}
Don’t guess—look it up.
Look for your function in the interface file, then for the third field in the pragma; it should say Strictness: ⟨string⟩. The ⟨string⟩ gives the strictness of the function’s arguments: see the GHC Commentary for a description of the strictness notation.
For an “unpackable” U(...) argument, the info inside tells the strictness of its components. So, if the argument is a pair, and it says U(AU(LSS)), that means “the first component of the pair isn’t used; the second component is itself unpackable, with three components (lazy in the first, strict in the second \& third).”
If the function isn’t exported, just compile with the extra flag -ddump-simpl; next to the signature for any binder, it will print the self-same pragmatic information as would be put in an interface file. (Besides, Core syntax is fun to look at!)
If you do not have an explicit export list in a module, GHC must assume that everything in that module will be exported. This has various pessimising effects. For example, if a bit of code is actually unused (perhaps because of unfolding effects), GHC will not be able to throw it away, because it is exported and some other module may be relying on its existence.
GHC can be quite a bit more aggressive with pieces of code if it knows they are not exported.
(The form in which GHC manipulates your code.) Just run your compilation with -ddump-simpl (don’t forget the -O).
If profiling has pointed the finger at particular functions, look at their Core code. lets are bad, cases are good, dictionaries (d.⟨Class⟩.⟨Unique⟩) [or anything overloading-ish] are bad, nested lambdas are bad, explicit data constructors are good, primitive operations (e.g., eqInt#) are good, ...
Putting a strictness annotation (!) on a constructor field helps in two ways: it adds strictness to the program, which gives the strictness analyser more to work with, and it might help to reduce space leaks.
It can also help in a third way: when used with -funbox-strict-fields (see -f*: platform-independent flags), a strict field can be unpacked or unboxed in the constructor, and one or more levels of indirection may be removed. Unpacking only happens for single-constructor datatypes (Int is a good candidate, for example).
Using -funbox-strict-fields is only really a good idea in conjunction with -O, because otherwise the extra packing and unpacking won’t be optimised away. In fact, it is possible that -funbox-strict-fields may worsen performance even with -O, but this is unlikely (let us know if it happens to you).
When you are really desperate for speed, and you want to get right down to the “raw bits.” Please see Unboxed types for some information about using unboxed types.
Before resorting to explicit unboxed types, try using strict constructor fields and -funbox-strict-fields first (see above). That way, your code stays portable.
This may take real work, but… There exist piles of massively-tuned library code, and the best thing is not to compete with it, but link with it.
Foreign function interface (FFI) describes the foreign function interface.
If you’re using Complex, definitely use Complex Double rather than Complex Float (the former is specialised heavily, but the latter isn’t).
Floats (probably 32-bits) are almost always a bad idea, anyway, unless you Really Know What You Are Doing. Use Doubles. There’s rarely a speed disadvantage—modern machines will use the same floating-point unit for both. With Doubles, you are much less likely to hang yourself with numerical errors.
One time when Float might be a good idea is if you have a lot of them, say a giant array of Floats. They take up half the space in the heap compared to Doubles. However, this isn’t true on a 64-bit machine.
Decrease the “go-for-it” threshold for unfolding smallish expressions. Give a -funfolding-use-threshold0 option for the extreme case. (“Only unfoldings with zero cost should proceed.”) Warning: except in certain specialised cases (like Happy parsers) this is likely to actually increase the size of your program, because unfolding generally enables extra simplifying optimisations to be performed.
Avoid Read.
Use strip on your executables.
“I think I have a space leak...”
Re-run your program with +RTS -S, and remove all doubt! (You’ll see the heap usage get bigger and bigger...) (Hmmm... this might be even easier with the -G1 RTS option; so... ./a.out +RTS -S -G1)
Once again, the profiling facilities (Profiling) are the basic tool for demystifying the space behaviour of your program.
Strict functions are good for space usage, as they are for time, as discussed in the previous section. Strict functions get right down to business, rather than filling up the heap with closures (the system’s notes to itself about how to evaluate something, should it eventually be required).