X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fsooner.xml;h=bb2eb871ec0e2d6c6f9484848839a4c2be36afa1;hb=b779271a1f1420c0894e721a75afece2c5e75147;hp=1aba5d1af0afb4ffa66c489d98c93373f6875da2;hpb=0065d5ab628975892cea1ec7303f968c3338cbe1;p=ghc-hetmet.git
diff --git a/docs/users_guide/sooner.xml b/docs/users_guide/sooner.xml
index 1aba5d1..bb2eb87 100644
--- a/docs/users_guide/sooner.xml
+++ b/docs/users_guide/sooner.xml
@@ -37,20 +37,13 @@ should go here!
error.)
If it says you're using more than 20% of total
- time in garbage collecting, then more memory would
- help.
-
- If the heap size is approaching the maximum (64M by
- default), and you have lots of memory, try increasing the
- maximum with the
- -M<size>
- option option, e.g.: ghc -c
- -O -M1024m Foo.hs.
-
- Increasing the default allocation area size used by
+ time in garbage collecting, then more memory might
+ help: use the
+
+ option. Increasing the default allocation area size used by
the compiler's RTS might also help: use the
- -A<size>
- option option.
+ -A<size>
+ RTS option option.
If GHC persists in being a bad memory citizen, please
report it as a bug.
@@ -101,48 +94,13 @@ should go here!
GHC compiles some program constructs slowly:
- Deeply-nested list comprehensions seem to be one such;
- in the past, very large constant tables were bad,
- too.
-
We'd rather you reported such behaviour as a bug, so
that we can try to correct it.
- 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
- .
- -fno-strictness
- anti-option
-
To figure out which part of the compiler is badly
behaved, the
option is your friend.
-
- 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
- -fvia-C
- option (not that GCC will be that
- quick about it, either).
-
-
-
-
- Explicit import declarations:
-
- Instead of saying import Foo, say
- import Foo (...stuff I want...) You can
- get GHC to tell you the minimal set of required imports by
- using the option
- (see ).
-
- Truthfully, the reduction on compilation time will be
- very small. However, judicious use of
- import declarations can make a program
- easier to understand, so it may be a good idea
- anyway.
@@ -200,9 +158,6 @@ should go here!
mind-bogglingly clever. Better to let GCC have a go, as it
tries much harder on register allocation, etc.
- At the moment, if you turn on you
- get GCC instead. This may change in the future.
-
So, when we want very fast code, we use: .
@@ -509,18 +464,6 @@ f (Wibble x y) # ugly, and proud of it
-A<size>
RTS option RTS options (see ).
-
- This is especially important if your program uses a
- lot of mutable arrays of pointers or mutable variables
- (i.e. STArray,
- IOArray, STRef and
- IORef, but not UArray,
- STUArray or IOUArray).
- 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.