<Chapter id="sooner-faster-quicker">
-<Title>Advice on: sooner, faster, smaller, stingier
+<Title>Advice on: sooner, faster, smaller, thriftier
</Title>
<Para>
<ListItem>
<Para>
Within reason, more memory for heap space means less garbage
-collection for GHC, which means less compilation time. If you use
-the <Option>-Rgc-stats</Option> option, you'll get a garbage-collector report.
-(Again, you can use the cheap-and-nasty <Option>-optCrts-Sstderr</Option> option to
-send the GC stats straight to standard error.)
+collection for GHC, which means less compilation time. If you use the
+<Option>-Rghc-timing</Option> option, you'll get a garbage-collector
+report. (Again, you can use the cheap-and-nasty <Option>+RTS -Sstderr
+-RTS</Option> option to send the GC stats straight to standard error.)
</Para>
<Para>
</Para>
<Para>
-The parts of the compiler that seem most prone to wandering off for a
-long time are the abstract interpreters (strictness and update
-analysers). You can turn these off individually with
-<Option>-fno-strictness</Option><IndexTerm><Primary>-fno-strictness anti-option</Primary></IndexTerm> and
-<Option>-fno-update-analysis</Option>.<IndexTerm><Primary>-fno-update-analysis anti-option</Primary></IndexTerm>
+The part of the compiler that is occasionally prone to wandering off
+for a long time is the strictness analyser. You can turn this off
+individually with <Option>-fno-strictness</Option>.
+<IndexTerm><Primary>-fno-strictness anti-option</Primary></IndexTerm>
</Para>
<Para>
To figure out which part of the compiler is badly behaved, the
-<Option>-dshow-passes</Option><IndexTerm><Primary>-dshow-passes option</Primary></IndexTerm> option is your
-friend.
+<option>-v2</option><indexterm><primary><option>-v</option></primary>
+</indexterm> option is your friend.
</Para>
<Para>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>Avoid the consistency-check on linking:</Term>
-<ListItem>
-<Para>
-Use <Option>-no-link-chk</Option><IndexTerm><Primary>-no-link-chk</Primary></IndexTerm>; saves effort. This is
-probably safe in a I-only-compile-things-one-way setup.
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
<Term>Explicit <Literal>import</Literal> declarations:</Term>
<ListItem>
<Para>
-Instead of saying <Literal>import Foo</Literal>, say <Literal>import Foo (...stuff I want...)</Literal>.
+Instead of saying <Literal>import Foo</Literal>, say <Literal>import
+Foo (...stuff I want...)</Literal> You can get GHC to tell you the
+minimal set of required imports by using the
+<option>-ddump-minimal-imports</option> option (see <xref
+linkend="hi-options">).
</Para>
<Para>
<Term>Compile via C and crank up GCC:</Term>
<ListItem>
<Para>
-Even with <Option>-O</Option>, GHC tries to
-use a native-code generator, if available. But 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.
-</Para>
+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.</para>
+
+<para>At the moment, if you turn on <option>-O</option> you get GCC
+instead. This may change in the future.</para>
<Para>
-So, when we want very fast code, we use: <Option>-O -fvia-C -O2-for-C</Option>.
+So, when we want very fast code, we use: <Option>-O -fvia-C</Option>.
</Para>
</ListItem>
</VarListEntry>
<Para>
Look for your function in the interface file, then for the third field
-in the pragma; it should say <Literal>_S_ <string></Literal>. The <Literal><string></Literal>
-gives the strictness of the function's arguments. <Function>L</Function> is lazy
-(bad), <Function>S</Function> and <Function>E</Function> are strict (good), <Function>P</Function> is “primitive” (good),
-<Function>U(...)</Function> is strict and
-“unpackable” (very good), and <Function>A</Function> is absent (very good).
+in the pragma; it should say <Literal>__S
+<string></Literal>. The <Literal><string></Literal> gives
+the strictness of the function's arguments. <Function>L</Function> is
+lazy (bad), <Function>S</Function> and <Function>E</Function> are
+strict (good), <Function>P</Function> is “primitive”
+(good), <Function>U(...)</Function> is strict and
+“unpackable” (very good), and <Function>A</Function> is
+absent (very good).
</Para>
<Para>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>Use <Function>_ccall_s</Function> (a GHC extension) to plug into fast libraries:</Term>
+<Term>Use <Literal>foreign import</Literal> (a GHC extension) to plug into fast libraries:</Term>
<ListItem>
<Para>
This may take real work, but… There exist piles of
</Para>
<Para>
-<XRef LinkEnd="glasgow-ccalls"> says a little about how to use C calls.
+<XRef LinkEnd="ffi"> describes the foreign function interface.
</Para>
</ListItem>
</VarListEntry>
+
<VarListEntry>
<Term>Don't use <Literal>Float</Literal>s:</Term>
<ListItem>
<Para>
-We don't provide specialisations of Prelude functions for <Literal>Float</Literal>
-(but we do for <Literal>Double</Literal>). If you end up executing overloaded
-code, you will lose on performance, perhaps badly.
-</Para>
+If you're using <literal>Complex</literal>, definitely use
+<literal>Complex Double</literal> rather than <literal>Complex
+Float</literal> (the former is specialised heavily, but the latter
+isn't).</para>
<Para>
<Literal>Floats</Literal> (probably 32-bits) are almost always a bad idea, anyway,
expressions. Give a
<Option>-funfolding-use-threshold0</Option><IndexTerm><Primary>-funfolding-use-threshold0
option</Primary></IndexTerm> option for the extreme case. (“Only unfoldings with
-zero cost should proceed.”) Warning: except in certain specialiised
+zero cost should proceed.”) Warning: except in certain specialised
cases (like Happy parsers) this is likely to actually
<Emphasis>increase</Emphasis> the size of your program, because unfolding
generally enables extra simplifying optimisations to be performed.
</Sect1>
-<Sect1 id="stingier">
-<Title>Stingier: producing a program that gobbles less heap space
+<Sect1 id="thriftier">
+<Title>Thriftier: producing a program that gobbles less heap space
</Title>
<Para>
</Para>
<Para>
-“I think I have a space leak…” Re-run your program with
-<Option>+RTS -Sstderr</Option>,<IndexTerm><Primary>-Sstderr RTS option</Primary></IndexTerm> and remove all doubt!
-(You'll see the heap usage get bigger and bigger…) [Hmmm…this
-might be even easier with the <Option>-F2s</Option><IndexTerm><Primary>-F2s RTS option</Primary></IndexTerm> RTS
-option; so… <Command>./a.out +RTS -Sstderr -F2s</Command>...]
+“I think I have a space leak…” Re-run your program
+with <Option>+RTS -Sstderr</Option>, and remove all doubt! (You'll
+see the heap usage get bigger and bigger…)
+[Hmmm…this might be even easier with the
+<Option>-G1</Option> RTS option; so… <Command>./a.out +RTS
+-Sstderr -G1</Command>...]
+<IndexTerm><Primary>-G RTS option</Primary></IndexTerm>
+<IndexTerm><Primary>-Sstderr RTS option</Primary></IndexTerm>
</Para>
<Para>
-Once again, the profiling facilities (<XRef LinkEnd="profiling">) are the basic tool for demystifying the space
-behaviour of your program.
+Once again, the profiling facilities (<XRef LinkEnd="profiling">) are
+the basic tool for demystifying the space behaviour of your program.
</Para>
<Para>
</Sect1>
</Chapter>
+
+<!-- Emacs stuff:
+ ;;; Local Variables: ***
+ ;;; mode: sgml ***
+ ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter") ***
+ ;;; End: ***
+ -->
projects / ghc-hetmet.git / blobdiff