garbage 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>
+ the cheap-and-nasty <option>+RTS -S -RTS</option>
option to send the GC stats straight to standard
error.)</para>
<para>If it says you're using more than 20% of total
- time in garbage collecting, then more memory would
- help.</para>
-
- <para>If the heap size is approaching the maximum (64M by
- default), and you have lots of memory, try increasing the
- maximum with the
- <option>-M<size></option><indexterm><primary>-M<size>
- option</primary></indexterm> option, e.g.: <command>ghc -c
- -O -M1024m Foo.hs</command>.</para>
-
- <para>Increasing the default allocation area size used by
+ time in garbage collecting, then more memory might
+ help: use the
+ <option>-H<size></option><indexterm><primary><option>-H</option></primary></indexterm>
+ option. Increasing the default allocation area size used by
the compiler's RTS might also help: use the
- <option>-A<size></option><indexterm><primary>-A<size>
- option</primary></indexterm> option.</para>
+ <option>+RTS -A<size> -RTS</option><indexterm><primary>-A<size>
+ RTS option</primary></indexterm> option.</para>
<para>If GHC persists in being a bad memory citizen, please
report it as a bug.</para>
<varlistentry>
<term>GHC compiles some program constructs slowly:</term>
<listitem>
- <para>Deeply-nested list comprehensions seem to be one such;
- in the past, very large constant tables were bad,
- too.</para>
-
<para>We'd rather you reported such behaviour as a bug, so
that we can try to correct it.</para>
- <para>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>-v2</option><indexterm><primary><option>-v</option></primary>
</indexterm> option is your friend.</para>
-
- <para>If your module has big wads of constant data, GHC may
- produce a huge basic block that will cause the native-code
- generator's register allocator to founder. Bring on
- <option>-fvia-C</option><indexterm><primary>-fvia-C
- option</primary></indexterm> (not that GCC will be that
- quick about it, either).</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> 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>Truthfully, the reduction on compilation time will be
- very small. However, judicious use of
- <literal>import</literal> declarations can make a program
- easier to understand, so it may be a good idea
- anyway.</para>
</listitem>
</varlistentry>
</variablelist>
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</option>.</para>
</listitem>
<option>-A<size></option><indexterm><primary>-A<size>
RTS option</primary></indexterm> RTS options (see <xref
linkend="rts-options-gc"/>).</para>
-
- <para>This is especially important if your program uses a
- lot of mutable arrays of pointers or mutable variables
- (i.e. <literal>STArray</literal>,
- <literal>IOArray</literal>, <literal>STRef</literal> and
- <literal>IORef</literal>, but not <literal>UArray</literal>,
- <literal>STUArray</literal> or <literal>IOUArray</literal>).
- 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.</para>
</listitem>
</varlistentry>
</variablelist>
<para>
“I think I have a space leak…” Re-run your program
-with <option>+RTS -Sstderr</option>, and remove all doubt! (You'll
+with <option>+RTS -S</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>...]
+-S -G1</command>...]
<indexterm><primary>-G RTS option</primary></indexterm>
-<indexterm><primary>-Sstderr RTS option</primary></indexterm>
+<indexterm><primary>-S RTS option</primary></indexterm>
</para>
<para>