1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <chapter id="sooner-faster-quicker">
3 <title>Advice on: sooner, faster, smaller, thriftier</title>
5 <para>Please advise us of other “helpful hints” that
9 <title>Sooner: producing a program more quickly
12 <indexterm><primary>compiling faster</primary></indexterm>
13 <indexterm><primary>faster compiling</primary></indexterm>
17 <term>Don't use <option>-O</option> or (especially) <option>-O2</option>:</term>
19 <para>By using them, you are telling GHC that you are
20 willing to suffer longer compilation times for
21 better-quality code.</para>
23 <para>GHC is surprisingly zippy for normal compilations
24 without <option>-O</option>!</para>
29 <term>Use more memory:</term>
31 <para>Within reason, more memory for heap space means less
32 garbage collection for GHC, which means less compilation
33 time. If you use the <option>-Rghc-timing</option> option,
34 you'll get a garbage-collector report. (Again, you can use
35 the cheap-and-nasty <option>+RTS -S -RTS</option>
36 option to send the GC stats straight to standard
39 <para>If it says you're using more than 20% of total
40 time in garbage collecting, then more memory might
42 <option>-H<size></option><indexterm><primary><option>-H</option></primary></indexterm>
43 option. Increasing the default allocation area size used by
44 the compiler's RTS might also help: use the
45 <option>+RTS -A<size> -RTS</option><indexterm><primary>-A<size>
46 RTS option</primary></indexterm> option.</para>
48 <para>If GHC persists in being a bad memory citizen, please
49 report it as a bug.</para>
54 <term>Don't use too much memory!</term>
56 <para>As soon as GHC plus its “fellow citizens”
57 (other processes on your machine) start using more than the
58 <emphasis>real memory</emphasis> on your machine, and the
59 machine starts “thrashing,” <emphasis>the party
60 is over</emphasis>. Compile times will be worse than
61 terrible! Use something like the csh-builtin
62 <command>time</command> command to get a report on how many
63 page faults you're getting.</para>
65 <para>If you don't know what virtual memory, thrashing, and
66 page faults are, or you don't know the memory configuration
67 of your machine, <emphasis>don't</emphasis> try to be clever
68 about memory use: you'll just make your life a misery (and
69 for other people, too, probably).</para>
74 <term>Try to use local disks when linking:</term>
76 <para>Because Haskell objects and libraries tend to be
77 large, it can take many real seconds to slurp the bits
78 to/from a remote filesystem.</para>
80 <para>It would be quite sensible to
81 <emphasis>compile</emphasis> on a fast machine using
82 remotely-mounted disks; then <emphasis>link</emphasis> on a
83 slow machine that had your disks directly mounted.</para>
88 <term>Don't derive/use <function>Read</function> unnecessarily:</term>
90 <para>It's ugly and slow.</para>
95 <term>GHC compiles some program constructs slowly:</term>
97 <para>We'd rather you reported such behaviour as a bug, so
98 that we can try to correct it.</para>
100 <para>To figure out which part of the compiler is badly
102 <option>-v2</option><indexterm><primary><option>-v</option></primary>
103 </indexterm> option is your friend.</para>
110 <title>Faster: producing a program that runs quicker</title>
112 <indexterm><primary>faster programs, how to produce</primary></indexterm>
114 <para>The key tool to use in making your Haskell program run
115 faster are GHC's profiling facilities, described separately in
116 <xref linkend="profiling"/>. There is <emphasis>no
117 substitute</emphasis> for finding where your program's time/space
118 is <emphasis>really</emphasis> going, as opposed to where you
119 imagine it is going.</para>
121 <para>Another point to bear in mind: By far the best way to
122 improve a program's performance <emphasis>dramatically</emphasis>
123 is to use better algorithms. Once profiling has thrown the
124 spotlight on the guilty time-consumer(s), it may be better to
125 re-think your program than to try all the tweaks listed below.</para>
127 <para>Another extremely efficient way to make your program snappy
128 is to use library code that has been Seriously Tuned By Someone
129 Else. You <emphasis>might</emphasis> be able to write a better
130 quicksort than the one in <literal>Data.List</literal>, but it
131 will take you much longer than typing <literal>import
132 Data.List</literal>.</para>
134 <para>Please report any overly-slow GHC-compiled programs. Since
135 GHC doesn't have any credible competition in the performance
136 department these days it's hard to say what overly-slow means, so
137 just use your judgement! Of course, if a GHC compiled program
138 runs slower than the same program compiled with NHC or Hugs, then
139 it's definitely a bug.</para>
143 <term>Optimise, using <option>-O</option> or <option>-O2</option>:</term>
145 <para>This is the most basic way to make your program go
146 faster. Compilation time will be slower, especially with
147 <option>-O2</option>.</para>
149 <para>At present, <option>-O2</option> is nearly
150 indistinguishable from <option>-O</option>.</para>
155 <term>Compile via LLVM:</term>
157 <para>The LLVM code generator can sometimes do a far better job
158 at producing fast code then either the native code generator
159 or the C code generator. This is not universal and depends
160 on the code. Numeric heavy code seems to show the best
161 improvement when compiled via LLVM.</para>
166 <term>Compile via C and crank up GCC:</term>
168 <para>The native code-generator is designed to be quick, not
169 mind-bogglingly clever. Better to let GCC have a go, as it
170 tries much harder on register allocation, etc.</para>
172 <para>So, when we want very fast code, we use: <option>-O
173 -fvia-C</option>.</para>
178 <term>Overloaded functions are not your friend:</term>
180 <para>Haskell's overloading (using type classes) is elegant,
181 neat, etc., etc., but it is death to performance if left to
182 linger in an inner loop. How can you squash it?</para>
186 <term>Give explicit type signatures:</term>
188 <para>Signatures are the basic trick; putting them on
189 exported, top-level functions is good
190 software-engineering practice, anyway. (Tip: using
191 <option>-fwarn-missing-signatures</option><indexterm><primary>-fwarn-missing-signatures
192 option</primary></indexterm> can help enforce good
193 signature-practice).</para>
195 <para>The automatic specialisation of overloaded
196 functions (with <option>-O</option>) should take care
197 of overloaded local and/or unexported functions.</para>
202 <term>Use <literal>SPECIALIZE</literal> pragmas:</term>
204 <indexterm><primary>SPECIALIZE pragma</primary></indexterm>
205 <indexterm><primary>overloading, death to</primary></indexterm>
207 <para>Specialize the overloading on key functions in
208 your program. See <xref linkend="specialize-pragma"/>
209 and <xref linkend="specialize-instance-pragma"/>.</para>
214 <term>“But how do I know where overloading is creeping in?”:</term>
216 <para>A low-tech way: grep (search) your interface
217 files for overloaded type signatures. You can view
218 interface files using the
219 <option>--show-iface</option> option (see <xref
220 linkend="hi-options"/>).
223 % ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
233 <term>Strict functions are your dear friends:</term>
235 <para>and, among other things, lazy pattern-matching is your
238 <para>(If you don't know what a “strict
239 function” is, please consult a functional-programming
240 textbook. A sentence or two of explanation here probably
241 would not do much good.)</para>
243 <para>Consider these two code fragments:
246 f (Wibble x y) = ... # strict
248 f arg = let { (Wibble x y) = arg } in ... # lazy
251 The former will result in far better code.</para>
253 <para>A less contrived example shows the use of
254 <literal>cases</literal> instead of <literal>lets</literal>
255 to get stricter code (a good thing):
258 f (Wibble x y) # beautiful but slow
260 (a1, b1, c1) = unpackFoo x
261 (a2, b2, c2) = unpackFoo y
264 f (Wibble x y) # ugly, and proud of it
265 = case (unpackFoo x) of { (a1, b1, c1) ->
266 case (unpackFoo y) of { (a2, b2, c2) ->
276 <term>GHC loves single-constructor data-types:</term>
278 <para>It's all the better if a function is strict in a
279 single-constructor type (a type with only one
280 data-constructor; for example, tuples are single-constructor
286 <term>Newtypes are better than datatypes:</term>
288 <para>If your datatype has a single constructor with a
289 single field, use a <literal>newtype</literal> declaration
290 instead of a <literal>data</literal> declaration. The
291 <literal>newtype</literal> will be optimised away in most
297 <term>“How do I find out a function's strictness?”</term>
299 <para>Don't guess—look it up.</para>
301 <para>Look for your function in the interface file, then for
302 the third field in the pragma; it should say
303 <literal>__S <string></literal>. The
304 <literal><string></literal> gives the strictness of
305 the function's arguments. <function>L</function> is lazy
306 (bad), <function>S</function> and <function>E</function> are
307 strict (good), <function>P</function> is
308 “primitive” (good), <function>U(...)</function>
309 is strict and “unpackable” (very good), and
310 <function>A</function> is absent (very good).</para>
312 <para>For an “unpackable”
313 <function>U(...)</function> argument, the info inside tells
314 the strictness of its components. So, if the argument is a
315 pair, and it says <function>U(AU(LSS))</function>, that
316 means “the first component of the pair isn't used; the
317 second component is itself unpackable, with three components
318 (lazy in the first, strict in the second \&
319 third).”</para>
321 <para>If the function isn't exported, just compile with the
322 extra flag <option>-ddump-simpl</option>; next to the
323 signature for any binder, it will print the self-same
324 pragmatic information as would be put in an interface file.
325 (Besides, Core syntax is fun to look at!)</para>
330 <term>Force key functions to be <literal>INLINE</literal>d (esp. monads):</term>
332 <para>Placing <literal>INLINE</literal> pragmas on certain
333 functions that are used a lot can have a dramatic effect.
334 See <xref linkend="inline-pragma"/>.</para>
339 <term>Explicit <literal>export</literal> list:</term>
341 <para>If you do not have an explicit export list in a
342 module, GHC must assume that everything in that module will
343 be exported. This has various pessimising effects. For
344 example, if a bit of code is actually
345 <emphasis>unused</emphasis> (perhaps because of unfolding
346 effects), GHC will not be able to throw it away, because it
347 is exported and some other module may be relying on its
350 <para>GHC can be quite a bit more aggressive with pieces of
351 code if it knows they are not exported.</para>
356 <term>Look at the Core syntax!</term>
358 <para>(The form in which GHC manipulates your code.) Just
359 run your compilation with <option>-ddump-simpl</option>
360 (don't forget the <option>-O</option>).</para>
362 <para>If profiling has pointed the finger at particular
363 functions, look at their Core code. <literal>lets</literal>
364 are bad, <literal>cases</literal> are good, dictionaries
365 (<literal>d.<Class>.<Unique></literal>) [or
366 anything overloading-ish] are bad, nested lambdas are
367 bad, explicit data constructors are good, primitive
368 operations (e.g., <literal>eqInt#</literal>) are
374 <term>Use strictness annotations:</term>
376 <para>Putting a strictness annotation ('!') on a constructor
377 field helps in two ways: it adds strictness to the program,
378 which gives the strictness analyser more to work with, and
379 it might help to reduce space leaks.</para>
381 <para>It can also help in a third way: when used with
382 <option>-funbox-strict-fields</option> (see <xref
383 linkend="options-f"/>), a strict field can be unpacked or
384 unboxed in the constructor, and one or more levels of
385 indirection may be removed. Unpacking only happens for
386 single-constructor datatypes (<literal>Int</literal> is a
387 good candidate, for example).</para>
389 <para>Using <option>-funbox-strict-fields</option> is only
390 really a good idea in conjunction with <option>-O</option>,
391 because otherwise the extra packing and unpacking won't be
392 optimised away. In fact, it is possible that
393 <option>-funbox-strict-fields</option> may worsen
394 performance even <emphasis>with</emphasis>
395 <option>-O</option>, but this is unlikely (let us know if it
396 happens to you).</para>
401 <term>Use unboxed types (a GHC extension):</term>
403 <para>When you are <emphasis>really</emphasis> desperate for
404 speed, and you want to get right down to the “raw
405 bits.” Please see <xref linkend="glasgow-unboxed"/> for
406 some information about using unboxed types.</para>
408 <para>Before resorting to explicit unboxed types, try using
409 strict constructor fields and
410 <option>-funbox-strict-fields</option> first (see above).
411 That way, your code stays portable.</para>
416 <term>Use <literal>foreign import</literal> (a GHC extension) to plug into fast libraries:</term>
418 <para>This may take real work, but… There exist piles
419 of massively-tuned library code, and the best thing is not
420 to compete with it, but link with it.</para>
422 <para><xref linkend="ffi"/> describes the foreign function
428 <term>Don't use <literal>Float</literal>s:</term>
430 <para>If you're using <literal>Complex</literal>, definitely
431 use <literal>Complex Double</literal> rather than
432 <literal>Complex Float</literal> (the former is specialised
433 heavily, but the latter isn't).</para>
435 <para><literal>Floats</literal> (probably 32-bits) are
436 almost always a bad idea, anyway, unless you Really Know
437 What You Are Doing. Use <literal>Double</literal>s.
438 There's rarely a speed disadvantage—modern machines
439 will use the same floating-point unit for both. With
440 <literal>Double</literal>s, you are much less likely to hang
441 yourself with numerical errors.</para>
443 <para>One time when <literal>Float</literal> might be a good
444 idea is if you have a <emphasis>lot</emphasis> of them, say
445 a giant array of <literal>Float</literal>s. They take up
446 half the space in the heap compared to
447 <literal>Doubles</literal>. However, this isn't true on a
448 64-bit machine.</para>
453 <term>Use unboxed arrays (<literal>UArray</literal>)</term>
455 <para>GHC supports arrays of unboxed elements, for several
456 basic arithmetic element types including
457 <literal>Int</literal> and <literal>Char</literal>: see the
458 <literal>Data.Array.Unboxed</literal> library for details.
459 These arrays are likely to be much faster than using
460 standard Haskell 98 arrays from the
461 <literal>Data.Array</literal> library.</para>
466 <term>Use a bigger heap!</term>
468 <para>If your program's GC stats
469 (<option>-S</option><indexterm><primary>-S RTS
470 option</primary></indexterm> RTS option) indicate that it's
471 doing lots of garbage-collection (say, more than 20%
472 of execution time), more memory might help—with the
473 <option>-M<size></option><indexterm><primary>-M<size>
474 RTS option</primary></indexterm> or
475 <option>-A<size></option><indexterm><primary>-A<size>
476 RTS option</primary></indexterm> RTS options (see <xref
477 linkend="rts-options-gc"/>).</para>
485 <title>Smaller: producing a program that is smaller
489 <indexterm><primary>smaller programs, how to produce</primary></indexterm>
493 Decrease the “go-for-it” threshold for unfolding smallish
495 <option>-funfolding-use-threshold0</option><indexterm><primary>-funfolding-use-threshold0
496 option</primary></indexterm> option for the extreme case. (“Only unfoldings with
497 zero cost should proceed.”) Warning: except in certain specialised
498 cases (like Happy parsers) this is likely to actually
499 <emphasis>increase</emphasis> the size of your program, because unfolding
500 generally enables extra simplifying optimisations to be performed.
504 Avoid <function>Read</function>.
508 Use <literal>strip</literal> on your executables.
513 <sect1 id="thriftier">
514 <title>Thriftier: producing a program that gobbles less heap space
518 <indexterm><primary>memory, using less heap</primary></indexterm>
519 <indexterm><primary>space-leaks, avoiding</primary></indexterm>
520 <indexterm><primary>heap space, using less</primary></indexterm>
524 “I think I have a space leak…” Re-run your program
525 with <option>+RTS -S</option>, and remove all doubt! (You'll
526 see the heap usage get bigger and bigger…)
527 [Hmmm…this might be even easier with the
528 <option>-G1</option> RTS option; so… <command>./a.out +RTS
530 <indexterm><primary>-G RTS option</primary></indexterm>
531 <indexterm><primary>-S RTS option</primary></indexterm>
535 Once again, the profiling facilities (<xref linkend="profiling"/>) are
536 the basic tool for demystifying the space behaviour of your program.
540 Strict functions are good for space usage, as they are for time, as
541 discussed in the previous section. Strict functions get right down to
542 business, rather than filling up the heap with closures (the system's
543 notes to itself about how to evaluate something, should it eventually
552 ;;; Local Variables: ***
553 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***