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 -Sstderr -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 would
43 <para>If the heap size is approaching the maximum (64M by
44 default), and you have lots of memory, try increasing the
46 <option>-M<size></option><indexterm><primary>-M<size>
47 option</primary></indexterm> option, e.g.: <command>ghc -c
48 -O -M1024m Foo.hs</command>.</para>
50 <para>Increasing the default allocation area size used by
51 the compiler's RTS might also help: use the
52 <option>-A<size></option><indexterm><primary>-A<size>
53 option</primary></indexterm> option.</para>
55 <para>If GHC persists in being a bad memory citizen, please
56 report it as a bug.</para>
61 <term>Don't use too much memory!</term>
63 <para>As soon as GHC plus its “fellow citizens”
64 (other processes on your machine) start using more than the
65 <emphasis>real memory</emphasis> on your machine, and the
66 machine starts “thrashing,” <emphasis>the party
67 is over</emphasis>. Compile times will be worse than
68 terrible! Use something like the csh-builtin
69 <command>time</command> command to get a report on how many
70 page faults you're getting.</para>
72 <para>If you don't know what virtual memory, thrashing, and
73 page faults are, or you don't know the memory configuration
74 of your machine, <emphasis>don't</emphasis> try to be clever
75 about memory use: you'll just make your life a misery (and
76 for other people, too, probably).</para>
81 <term>Try to use local disks when linking:</term>
83 <para>Because Haskell objects and libraries tend to be
84 large, it can take many real seconds to slurp the bits
85 to/from a remote filesystem.</para>
87 <para>It would be quite sensible to
88 <emphasis>compile</emphasis> on a fast machine using
89 remotely-mounted disks; then <emphasis>link</emphasis> on a
90 slow machine that had your disks directly mounted.</para>
95 <term>Don't derive/use <function>Read</function> unnecessarily:</term>
97 <para>It's ugly and slow.</para>
102 <term>GHC compiles some program constructs slowly:</term>
104 <para>Deeply-nested list comprehensions seem to be one such;
105 in the past, very large constant tables were bad,
108 <para>We'd rather you reported such behaviour as a bug, so
109 that we can try to correct it.</para>
111 <para>The part of the compiler that is occasionally prone to
112 wandering off for a long time is the strictness analyser.
113 You can turn this off individually with
114 <option>-fno-strictness</option>.
115 <indexterm><primary>-fno-strictness
116 anti-option</primary></indexterm></para>
118 <para>To figure out which part of the compiler is badly
120 <option>-v2</option><indexterm><primary><option>-v</option></primary>
121 </indexterm> option is your friend.</para>
123 <para>If your module has big wads of constant data, GHC may
124 produce a huge basic block that will cause the native-code
125 generator's register allocator to founder. Bring on
126 <option>-fvia-C</option><indexterm><primary>-fvia-C
127 option</primary></indexterm> (not that GCC will be that
128 quick about it, either).</para>
133 <term>Explicit <literal>import</literal> declarations:</term>
135 <para>Instead of saying <literal>import Foo</literal>, say
136 <literal>import Foo (...stuff I want...)</literal> You can
137 get GHC to tell you the minimal set of required imports by
138 using the <option>-ddump-minimal-imports</option> option
139 (see <xref linkend="hi-options"/>).</para>
141 <para>Truthfully, the reduction on compilation time will be
142 very small. However, judicious use of
143 <literal>import</literal> declarations can make a program
144 easier to understand, so it may be a good idea
152 <title>Faster: producing a program that runs quicker</title>
154 <indexterm><primary>faster programs, how to produce</primary></indexterm>
156 <para>The key tool to use in making your Haskell program run
157 faster are GHC's profiling facilities, described separately in
158 <xref linkend="profiling"/>. There is <emphasis>no
159 substitute</emphasis> for finding where your program's time/space
160 is <emphasis>really</emphasis> going, as opposed to where you
161 imagine it is going.</para>
163 <para>Another point to bear in mind: By far the best way to
164 improve a program's performance <emphasis>dramatically</emphasis>
165 is to use better algorithms. Once profiling has thrown the
166 spotlight on the guilty time-consumer(s), it may be better to
167 re-think your program than to try all the tweaks listed below.</para>
169 <para>Another extremely efficient way to make your program snappy
170 is to use library code that has been Seriously Tuned By Someone
171 Else. You <emphasis>might</emphasis> be able to write a better
172 quicksort than the one in <literal>Data.List</literal>, but it
173 will take you much longer than typing <literal>import
174 Data.List</literal>.</para>
176 <para>Please report any overly-slow GHC-compiled programs. Since
177 GHC doesn't have any credible competition in the performance
178 department these days it's hard to say what overly-slow means, so
179 just use your judgement! Of course, if a GHC compiled program
180 runs slower than the same program compiled with NHC or Hugs, then
181 it's definitely a bug.</para>
185 <term>Optimise, using <option>-O</option> or <option>-O2</option>:</term>
187 <para>This is the most basic way to make your program go
188 faster. Compilation time will be slower, especially with
189 <option>-O2</option>.</para>
191 <para>At present, <option>-O2</option> is nearly
192 indistinguishable from <option>-O</option>.</para>
197 <term>Compile via C and crank up GCC:</term>
199 <para>The native code-generator is designed to be quick, not
200 mind-bogglingly clever. Better to let GCC have a go, as it
201 tries much harder on register allocation, etc.</para>
203 <para>So, when we want very fast code, we use: <option>-O
204 -fvia-C</option>.</para>
209 <term>Overloaded functions are not your friend:</term>
211 <para>Haskell's overloading (using type classes) is elegant,
212 neat, etc., etc., but it is death to performance if left to
213 linger in an inner loop. How can you squash it?</para>
217 <term>Give explicit type signatures:</term>
219 <para>Signatures are the basic trick; putting them on
220 exported, top-level functions is good
221 software-engineering practice, anyway. (Tip: using
222 <option>-fwarn-missing-signatures</option><indexterm><primary>-fwarn-missing-signatures
223 option</primary></indexterm> can help enforce good
224 signature-practice).</para>
226 <para>The automatic specialisation of overloaded
227 functions (with <option>-O</option>) should take care
228 of overloaded local and/or unexported functions.</para>
233 <term>Use <literal>SPECIALIZE</literal> pragmas:</term>
235 <indexterm><primary>SPECIALIZE pragma</primary></indexterm>
236 <indexterm><primary>overloading, death to</primary></indexterm>
238 <para>Specialize the overloading on key functions in
239 your program. See <xref linkend="specialize-pragma"/>
240 and <xref linkend="specialize-instance-pragma"/>.</para>
245 <term>“But how do I know where overloading is creeping in?”:</term>
247 <para>A low-tech way: grep (search) your interface
248 files for overloaded type signatures. You can view
249 interface files using the
250 <option>--show-iface</option> option (see <xref
251 linkend="hi-options"/>).
254 % ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
264 <term>Strict functions are your dear friends:</term>
266 <para>and, among other things, lazy pattern-matching is your
269 <para>(If you don't know what a “strict
270 function” is, please consult a functional-programming
271 textbook. A sentence or two of explanation here probably
272 would not do much good.)</para>
274 <para>Consider these two code fragments:
277 f (Wibble x y) = ... # strict
279 f arg = let { (Wibble x y) = arg } in ... # lazy
282 The former will result in far better code.</para>
284 <para>A less contrived example shows the use of
285 <literal>cases</literal> instead of <literal>lets</literal>
286 to get stricter code (a good thing):
289 f (Wibble x y) # beautiful but slow
291 (a1, b1, c1) = unpackFoo x
292 (a2, b2, c2) = unpackFoo y
295 f (Wibble x y) # ugly, and proud of it
296 = case (unpackFoo x) of { (a1, b1, c1) ->
297 case (unpackFoo y) of { (a2, b2, c2) ->
307 <term>GHC loves single-constructor data-types:</term>
309 <para>It's all the better if a function is strict in a
310 single-constructor type (a type with only one
311 data-constructor; for example, tuples are single-constructor
317 <term>Newtypes are better than datatypes:</term>
319 <para>If your datatype has a single constructor with a
320 single field, use a <literal>newtype</literal> declaration
321 instead of a <literal>data</literal> declaration. The
322 <literal>newtype</literal> will be optimised away in most
328 <term>“How do I find out a function's strictness?”</term>
330 <para>Don't guess—look it up.</para>
332 <para>Look for your function in the interface file, then for
333 the third field in the pragma; it should say
334 <literal>__S <string></literal>. The
335 <literal><string></literal> gives the strictness of
336 the function's arguments. <function>L</function> is lazy
337 (bad), <function>S</function> and <function>E</function> are
338 strict (good), <function>P</function> is
339 “primitive” (good), <function>U(...)</function>
340 is strict and “unpackable” (very good), and
341 <function>A</function> is absent (very good).</para>
343 <para>For an “unpackable”
344 <function>U(...)</function> argument, the info inside tells
345 the strictness of its components. So, if the argument is a
346 pair, and it says <function>U(AU(LSS))</function>, that
347 means “the first component of the pair isn't used; the
348 second component is itself unpackable, with three components
349 (lazy in the first, strict in the second \&
350 third).”</para>
352 <para>If the function isn't exported, just compile with the
353 extra flag <option>-ddump-simpl</option>; next to the
354 signature for any binder, it will print the self-same
355 pragmatic information as would be put in an interface file.
356 (Besides, Core syntax is fun to look at!)</para>
361 <term>Force key functions to be <literal>INLINE</literal>d (esp. monads):</term>
363 <para>Placing <literal>INLINE</literal> pragmas on certain
364 functions that are used a lot can have a dramatic effect.
365 See <xref linkend="inline-pragma"/>.</para>
370 <term>Explicit <literal>export</literal> list:</term>
372 <para>If you do not have an explicit export list in a
373 module, GHC must assume that everything in that module will
374 be exported. This has various pessimising effects. For
375 example, if a bit of code is actually
376 <emphasis>unused</emphasis> (perhaps because of unfolding
377 effects), GHC will not be able to throw it away, because it
378 is exported and some other module may be relying on its
381 <para>GHC can be quite a bit more aggressive with pieces of
382 code if it knows they are not exported.</para>
387 <term>Look at the Core syntax!</term>
389 <para>(The form in which GHC manipulates your code.) Just
390 run your compilation with <option>-ddump-simpl</option>
391 (don't forget the <option>-O</option>).</para>
393 <para>If profiling has pointed the finger at particular
394 functions, look at their Core code. <literal>lets</literal>
395 are bad, <literal>cases</literal> are good, dictionaries
396 (<literal>d.<Class>.<Unique></literal>) [or
397 anything overloading-ish] are bad, nested lambdas are
398 bad, explicit data constructors are good, primitive
399 operations (e.g., <literal>eqInt#</literal>) are
405 <term>Use strictness annotations:</term>
407 <para>Putting a strictness annotation ('!') on a constructor
408 field helps in two ways: it adds strictness to the program,
409 which gives the strictness analyser more to work with, and
410 it might help to reduce space leaks.</para>
412 <para>It can also help in a third way: when used with
413 <option>-funbox-strict-fields</option> (see <xref
414 linkend="options-f"/>), a strict field can be unpacked or
415 unboxed in the constructor, and one or more levels of
416 indirection may be removed. Unpacking only happens for
417 single-constructor datatypes (<literal>Int</literal> is a
418 good candidate, for example).</para>
420 <para>Using <option>-funbox-strict-fields</option> is only
421 really a good idea in conjunction with <option>-O</option>,
422 because otherwise the extra packing and unpacking won't be
423 optimised away. In fact, it is possible that
424 <option>-funbox-strict-fields</option> may worsen
425 performance even <emphasis>with</emphasis>
426 <option>-O</option>, but this is unlikely (let us know if it
427 happens to you).</para>
432 <term>Use unboxed types (a GHC extension):</term>
434 <para>When you are <emphasis>really</emphasis> desperate for
435 speed, and you want to get right down to the “raw
436 bits.” Please see <xref linkend="glasgow-unboxed"/> for
437 some information about using unboxed types.</para>
439 <para>Before resorting to explicit unboxed types, try using
440 strict constructor fields and
441 <option>-funbox-strict-fields</option> first (see above).
442 That way, your code stays portable.</para>
447 <term>Use <literal>foreign import</literal> (a GHC extension) to plug into fast libraries:</term>
449 <para>This may take real work, but… There exist piles
450 of massively-tuned library code, and the best thing is not
451 to compete with it, but link with it.</para>
453 <para><xref linkend="ffi"/> describes the foreign function
459 <term>Don't use <literal>Float</literal>s:</term>
461 <para>If you're using <literal>Complex</literal>, definitely
462 use <literal>Complex Double</literal> rather than
463 <literal>Complex Float</literal> (the former is specialised
464 heavily, but the latter isn't).</para>
466 <para><literal>Floats</literal> (probably 32-bits) are
467 almost always a bad idea, anyway, unless you Really Know
468 What You Are Doing. Use <literal>Double</literal>s.
469 There's rarely a speed disadvantage—modern machines
470 will use the same floating-point unit for both. With
471 <literal>Double</literal>s, you are much less likely to hang
472 yourself with numerical errors.</para>
474 <para>One time when <literal>Float</literal> might be a good
475 idea is if you have a <emphasis>lot</emphasis> of them, say
476 a giant array of <literal>Float</literal>s. They take up
477 half the space in the heap compared to
478 <literal>Doubles</literal>. However, this isn't true on a
479 64-bit machine.</para>
484 <term>Use unboxed arrays (<literal>UArray</literal>)</term>
486 <para>GHC supports arrays of unboxed elements, for several
487 basic arithmetic element types including
488 <literal>Int</literal> and <literal>Char</literal>: see the
489 <literal>Data.Array.Unboxed</literal> library for details.
490 These arrays are likely to be much faster than using
491 standard Haskell 98 arrays from the
492 <literal>Data.Array</literal> library.</para>
497 <term>Use a bigger heap!</term>
499 <para>If your program's GC stats
500 (<option>-S</option><indexterm><primary>-S RTS
501 option</primary></indexterm> RTS option) indicate that it's
502 doing lots of garbage-collection (say, more than 20%
503 of execution time), more memory might help—with the
504 <option>-M<size></option><indexterm><primary>-M<size>
505 RTS option</primary></indexterm> or
506 <option>-A<size></option><indexterm><primary>-A<size>
507 RTS option</primary></indexterm> RTS options (see <xref
508 linkend="rts-options-gc"/>).</para>
516 <title>Smaller: producing a program that is smaller
520 <indexterm><primary>smaller programs, how to produce</primary></indexterm>
524 Decrease the “go-for-it” threshold for unfolding smallish
526 <option>-funfolding-use-threshold0</option><indexterm><primary>-funfolding-use-threshold0
527 option</primary></indexterm> option for the extreme case. (“Only unfoldings with
528 zero cost should proceed.”) Warning: except in certain specialised
529 cases (like Happy parsers) this is likely to actually
530 <emphasis>increase</emphasis> the size of your program, because unfolding
531 generally enables extra simplifying optimisations to be performed.
535 Avoid <function>Read</function>.
539 Use <literal>strip</literal> on your executables.
544 <sect1 id="thriftier">
545 <title>Thriftier: producing a program that gobbles less heap space
549 <indexterm><primary>memory, using less heap</primary></indexterm>
550 <indexterm><primary>space-leaks, avoiding</primary></indexterm>
551 <indexterm><primary>heap space, using less</primary></indexterm>
555 “I think I have a space leak…” Re-run your program
556 with <option>+RTS -Sstderr</option>, and remove all doubt! (You'll
557 see the heap usage get bigger and bigger…)
558 [Hmmm…this might be even easier with the
559 <option>-G1</option> RTS option; so… <command>./a.out +RTS
560 -Sstderr -G1</command>...]
561 <indexterm><primary>-G RTS option</primary></indexterm>
562 <indexterm><primary>-Sstderr RTS option</primary></indexterm>
566 Once again, the profiling facilities (<xref linkend="profiling"/>) are
567 the basic tool for demystifying the space behaviour of your program.
571 Strict functions are good for space usage, as they are for time, as
572 discussed in the previous section. Strict functions get right down to
573 business, rather than filling up the heap with closures (the system's
574 notes to itself about how to evaluate something, should it eventually
583 ;;; Local Variables: ***
585 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***