X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fsooner.xml;h=d1aeb0f8884e77ee93e5ea5e98d001a437e4d8c8;hb=aedb94f5f220b5e442b23ecc445fd38c8d9b6ba0;hp=ec1bb3dc01807754a54729973db9c431e71d4b06;hpb=9744a9c7b9ca160c0dc3332c4c8a289e6a8fce6e;p=ghc-hetmet.git

diff --git a/docs/users_guide/sooner.xml b/docs/users_guide/sooner.xml
index ec1bb3d..d1aeb0f 100644
--- a/docs/users_guide/sooner.xml
+++ b/docs/users_guide/sooner.xml
@@ -32,25 +32,18 @@ should go here!</para>
           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&percnt; 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&lt;size&gt;</option><indexterm><primary>-M&lt;size&gt;
-          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&lt;size&gt;</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&lt;size&gt;</option><indexterm><primary>-A&lt;size&gt;
-          option</primary></indexterm> option.</para>
+          <option>+RTS -A&lt;size&gt; -RTS</option><indexterm><primary>-A&lt;size&gt;
+          RTS option</primary></indexterm> option.</para>
 
 	  <para>If GHC persists in being a bad memory citizen, please
           report it as a bug.</para>
@@ -101,48 +94,13 @@ should go here!</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>
@@ -200,9 +158,6 @@ should go here!</para>
           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>
@@ -556,13 +511,13 @@ Use <literal>strip</literal> on your executables.
 
 <para>
 &ldquo;I think I have a space leak&hellip;&rdquo; 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&hellip;)
 &lsqb;Hmmm&hellip;this might be even easier with the
 <option>-G1</option> RTS option; so&hellip; <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>