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>Overloaded functions are not your friend:</term>
168 <para>Haskell's overloading (using type classes) is elegant,
169 neat, etc., etc., but it is death to performance if left to
170 linger in an inner loop. How can you squash it?</para>
174 <term>Give explicit type signatures:</term>
176 <para>Signatures are the basic trick; putting them on
177 exported, top-level functions is good
178 software-engineering practice, anyway. (Tip: using
179 <option>-fwarn-missing-signatures</option><indexterm><primary>-fwarn-missing-signatures
180 option</primary></indexterm> can help enforce good
181 signature-practice).</para>
183 <para>The automatic specialisation of overloaded
184 functions (with <option>-O</option>) should take care
185 of overloaded local and/or unexported functions.</para>
190 <term>Use <literal>SPECIALIZE</literal> pragmas:</term>
192 <indexterm><primary>SPECIALIZE pragma</primary></indexterm>
193 <indexterm><primary>overloading, death to</primary></indexterm>
195 <para>Specialize the overloading on key functions in
196 your program. See <xref linkend="specialize-pragma"/>
197 and <xref linkend="specialize-instance-pragma"/>.</para>
202 <term>“But how do I know where overloading is creeping in?”:</term>
204 <para>A low-tech way: grep (search) your interface
205 files for overloaded type signatures. You can view
206 interface files using the
207 <option>--show-iface</option> option (see <xref
208 linkend="hi-options"/>).
211 % ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
221 <term>Strict functions are your dear friends:</term>
223 <para>and, among other things, lazy pattern-matching is your
226 <para>(If you don't know what a “strict
227 function” is, please consult a functional-programming
228 textbook. A sentence or two of explanation here probably
229 would not do much good.)</para>
231 <para>Consider these two code fragments:
234 f (Wibble x y) = ... # strict
236 f arg = let { (Wibble x y) = arg } in ... # lazy
239 The former will result in far better code.</para>
241 <para>A less contrived example shows the use of
242 <literal>cases</literal> instead of <literal>lets</literal>
243 to get stricter code (a good thing):
246 f (Wibble x y) # beautiful but slow
248 (a1, b1, c1) = unpackFoo x
249 (a2, b2, c2) = unpackFoo y
252 f (Wibble x y) # ugly, and proud of it
253 = case (unpackFoo x) of { (a1, b1, c1) ->
254 case (unpackFoo y) of { (a2, b2, c2) ->
264 <term>GHC loves single-constructor data-types:</term>
266 <para>It's all the better if a function is strict in a
267 single-constructor type (a type with only one
268 data-constructor; for example, tuples are single-constructor
274 <term>Newtypes are better than datatypes:</term>
276 <para>If your datatype has a single constructor with a
277 single field, use a <literal>newtype</literal> declaration
278 instead of a <literal>data</literal> declaration. The
279 <literal>newtype</literal> will be optimised away in most
285 <term>“How do I find out a function's strictness?”</term>
287 <para>Don't guess—look it up.</para>
289 <para>Look for your function in the interface file, then for
290 the third field in the pragma; it should say
291 <literal>__S <string></literal>. The
292 <literal><string></literal> gives the strictness of
293 the function's arguments. <function>L</function> is lazy
294 (bad), <function>S</function> and <function>E</function> are
295 strict (good), <function>P</function> is
296 “primitive” (good), <function>U(...)</function>
297 is strict and “unpackable” (very good), and
298 <function>A</function> is absent (very good).</para>
300 <para>For an “unpackable”
301 <function>U(...)</function> argument, the info inside tells
302 the strictness of its components. So, if the argument is a
303 pair, and it says <function>U(AU(LSS))</function>, that
304 means “the first component of the pair isn't used; the
305 second component is itself unpackable, with three components
306 (lazy in the first, strict in the second \&
307 third).”</para>
309 <para>If the function isn't exported, just compile with the
310 extra flag <option>-ddump-simpl</option>; next to the
311 signature for any binder, it will print the self-same
312 pragmatic information as would be put in an interface file.
313 (Besides, Core syntax is fun to look at!)</para>
318 <term>Force key functions to be <literal>INLINE</literal>d (esp. monads):</term>
320 <para>Placing <literal>INLINE</literal> pragmas on certain
321 functions that are used a lot can have a dramatic effect.
322 See <xref linkend="inline-pragma"/>.</para>
327 <term>Explicit <literal>export</literal> list:</term>
329 <para>If you do not have an explicit export list in a
330 module, GHC must assume that everything in that module will
331 be exported. This has various pessimising effects. For
332 example, if a bit of code is actually
333 <emphasis>unused</emphasis> (perhaps because of unfolding
334 effects), GHC will not be able to throw it away, because it
335 is exported and some other module may be relying on its
338 <para>GHC can be quite a bit more aggressive with pieces of
339 code if it knows they are not exported.</para>
344 <term>Look at the Core syntax!</term>
346 <para>(The form in which GHC manipulates your code.) Just
347 run your compilation with <option>-ddump-simpl</option>
348 (don't forget the <option>-O</option>).</para>
350 <para>If profiling has pointed the finger at particular
351 functions, look at their Core code. <literal>lets</literal>
352 are bad, <literal>cases</literal> are good, dictionaries
353 (<literal>d.<Class>.<Unique></literal>) [or
354 anything overloading-ish] are bad, nested lambdas are
355 bad, explicit data constructors are good, primitive
356 operations (e.g., <literal>eqInt#</literal>) are
362 <term>Use strictness annotations:</term>
364 <para>Putting a strictness annotation ('!') on a constructor
365 field helps in two ways: it adds strictness to the program,
366 which gives the strictness analyser more to work with, and
367 it might help to reduce space leaks.</para>
369 <para>It can also help in a third way: when used with
370 <option>-funbox-strict-fields</option> (see <xref
371 linkend="options-f"/>), a strict field can be unpacked or
372 unboxed in the constructor, and one or more levels of
373 indirection may be removed. Unpacking only happens for
374 single-constructor datatypes (<literal>Int</literal> is a
375 good candidate, for example).</para>
377 <para>Using <option>-funbox-strict-fields</option> is only
378 really a good idea in conjunction with <option>-O</option>,
379 because otherwise the extra packing and unpacking won't be
380 optimised away. In fact, it is possible that
381 <option>-funbox-strict-fields</option> may worsen
382 performance even <emphasis>with</emphasis>
383 <option>-O</option>, but this is unlikely (let us know if it
384 happens to you).</para>
389 <term>Use unboxed types (a GHC extension):</term>
391 <para>When you are <emphasis>really</emphasis> desperate for
392 speed, and you want to get right down to the “raw
393 bits.” Please see <xref linkend="glasgow-unboxed"/> for
394 some information about using unboxed types.</para>
396 <para>Before resorting to explicit unboxed types, try using
397 strict constructor fields and
398 <option>-funbox-strict-fields</option> first (see above).
399 That way, your code stays portable.</para>
404 <term>Use <literal>foreign import</literal> (a GHC extension) to plug into fast libraries:</term>
406 <para>This may take real work, but… There exist piles
407 of massively-tuned library code, and the best thing is not
408 to compete with it, but link with it.</para>
410 <para><xref linkend="ffi"/> describes the foreign function
416 <term>Don't use <literal>Float</literal>s:</term>
418 <para>If you're using <literal>Complex</literal>, definitely
419 use <literal>Complex Double</literal> rather than
420 <literal>Complex Float</literal> (the former is specialised
421 heavily, but the latter isn't).</para>
423 <para><literal>Floats</literal> (probably 32-bits) are
424 almost always a bad idea, anyway, unless you Really Know
425 What You Are Doing. Use <literal>Double</literal>s.
426 There's rarely a speed disadvantage—modern machines
427 will use the same floating-point unit for both. With
428 <literal>Double</literal>s, you are much less likely to hang
429 yourself with numerical errors.</para>
431 <para>One time when <literal>Float</literal> might be a good
432 idea is if you have a <emphasis>lot</emphasis> of them, say
433 a giant array of <literal>Float</literal>s. They take up
434 half the space in the heap compared to
435 <literal>Doubles</literal>. However, this isn't true on a
436 64-bit machine.</para>
441 <term>Use unboxed arrays (<literal>UArray</literal>)</term>
443 <para>GHC supports arrays of unboxed elements, for several
444 basic arithmetic element types including
445 <literal>Int</literal> and <literal>Char</literal>: see the
446 <literal>Data.Array.Unboxed</literal> library for details.
447 These arrays are likely to be much faster than using
448 standard Haskell 98 arrays from the
449 <literal>Data.Array</literal> library.</para>
454 <term>Use a bigger heap!</term>
456 <para>If your program's GC stats
457 (<option>-S</option><indexterm><primary>-S RTS
458 option</primary></indexterm> RTS option) indicate that it's
459 doing lots of garbage-collection (say, more than 20%
460 of execution time), more memory might help—with the
461 <option>-M<size></option><indexterm><primary>-M<size>
462 RTS option</primary></indexterm> or
463 <option>-A<size></option><indexterm><primary>-A<size>
464 RTS option</primary></indexterm> RTS options (see <xref
465 linkend="rts-options-gc"/>).</para>
473 <title>Smaller: producing a program that is smaller
477 <indexterm><primary>smaller programs, how to produce</primary></indexterm>
481 Decrease the “go-for-it” threshold for unfolding smallish
483 <option>-funfolding-use-threshold0</option><indexterm><primary>-funfolding-use-threshold0
484 option</primary></indexterm> option for the extreme case. (“Only unfoldings with
485 zero cost should proceed.”) Warning: except in certain specialised
486 cases (like Happy parsers) this is likely to actually
487 <emphasis>increase</emphasis> the size of your program, because unfolding
488 generally enables extra simplifying optimisations to be performed.
492 Avoid <function>Read</function>.
496 Use <literal>strip</literal> on your executables.
501 <sect1 id="thriftier">
502 <title>Thriftier: producing a program that gobbles less heap space
506 <indexterm><primary>memory, using less heap</primary></indexterm>
507 <indexterm><primary>space-leaks, avoiding</primary></indexterm>
508 <indexterm><primary>heap space, using less</primary></indexterm>
512 “I think I have a space leak…” Re-run your program
513 with <option>+RTS -S</option>, and remove all doubt! (You'll
514 see the heap usage get bigger and bigger…)
515 [Hmmm…this might be even easier with the
516 <option>-G1</option> RTS option; so… <command>./a.out +RTS
518 <indexterm><primary>-G RTS option</primary></indexterm>
519 <indexterm><primary>-S RTS option</primary></indexterm>
523 Once again, the profiling facilities (<xref linkend="profiling"/>) are
524 the basic tool for demystifying the space behaviour of your program.
528 Strict functions are good for space usage, as they are for time, as
529 discussed in the previous section. Strict functions get right down to
530 business, rather than filling up the heap with closures (the system's
531 notes to itself about how to evaluate something, should it eventually
540 ;;; Local Variables: ***
541 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***