6.2. Faster: producing a program that runs quicker

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.

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.

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?

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) -> ... }}

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

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.

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!)

Placing INLINE pragmas on certain functions that are used a lot can have a dramatic effect. See Section 7.7.1.

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 Section 4.11.2), 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 Section 7.2.1 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.

Chapter 8 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.

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.

If your program's GC stats (-S RTS option) indicate that it's doing lots of garbage-collection (say, more than 20% of execution time), more memory might help—with the -M<size> or -A<size> RTS options (see Section 4.16.2).

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.