6.2. Faster: producing a program that runs quicker

The key tool to use in making your Haskell program run
faster are GHC's profiling facilities, described separately in
Chapter 5, 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.

Optimise, using -O or -O2:

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.

Compile via C and crank up GCC:

The native code-generator is designed to be quick, not
mind-bogglingly clever. Better to let GCC have a go, as it
tries much harder on register allocation, etc.

At the moment, if you turn on -O you
get GCC instead. This may change in the future.

So, when we want very fast code, we use: -O
-fvia-C.

Overloaded functions are not your friend:

Haskell's overloading (using type classes) is elegant,
neat, etc., etc., but it is death to performance if left to
linger in an inner loop. How can you squash it?

Give explicit type signatures:

Signatures are the basic trick; putting them on
exported, top-level functions is good
software-engineering practice, anyway. (Tip: using
-fwarn-missing-signatures can help enforce good
signature-practice).

The automatic specialisation of overloaded
functions (with -O) should take care
of overloaded local and/or unexported functions.

It's all the better if a function is strict in a
single-constructor type (a type with only one
data-constructor; for example, tuples are single-constructor
types).

Newtypes are better than datatypes:

If your datatype has a single constructor with a
single field, use a newtype declaration
instead of a data declaration. The
newtype will be optimised away in most
cases.

“How do I find out a function's strictness?”

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
__S <string>. The
<string> gives the strictness of
the function's arguments. L is lazy
(bad), S and E are
strict (good), P is
“primitive” (good), U(...)
is strict and “unpackable” (very good), and
A is absent (very good).

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.

Look at the Core syntax!

(The form in which GHC manipulates your code.) Just
run your compilation with -ddump-simpl
(don't forget the -O).

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 Section 4.9.2, “-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).

Use unboxed types (a GHC extension):

When you are really desperate for
speed, and you want to get right down to the “raw
bits.” Please see Section 7.2.1, “Unboxed types
” for
some information about using unboxed types.

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.

Use unboxed arrays (UArray)

GHC supports arrays of unboxed elements, for several
basic arithmetic element types including
Int and Char: see the
Data.Array.Unboxed library for details.
These arrays are likely to be much faster than using
standard Haskell 98 arrays from the
Data.Array library.

This is especially important if your program uses a
lot of mutable arrays of pointers or mutable variables
(i.e. STArray,
IOArray, STRef and
IORef, but not UArray,
STUArray or IOUArray).
GHC's garbage collector currently scans these objects on
every collection, so your program won't benefit from
generational GC in the normal way if you use lots of
these. Increasing the heap size to reduce the number of
collections will probably help.