simonpj at microsoft.com
Tue Aug 17 11:06:37 EDT 2004
I had a look at this. It's an old chestnut: lazy pattern matching. You
let ((commands, s), x) = run (read iters) 5
in do ...do something with commands...
Trouble is, the 'x' hangs onto both components of the pair, even though
it only needs one.
It's not enough to force the pair earlier, which you probably tried,
because the state monad you are using is itself lazy, and uses masses of
lazy pattern matching.
You could return the state paired with each item, rather than just the
state at the end, perhaps, or use a stricter state monad.
This lazy-pattern-matching leak is a well-known problem, to which I do
not know a good solution. There was a paper from Chalmers about 8 years
ago about building more cleverness into the compiler, but it amounted to
extending Core with a lazy tuple binding. Fair enough, but quite a big
addition to Core and one I've never done.
better ideas welcome
| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
| bounces at haskell.org] On Behalf Of Ian Lynagh
| Sent: 12 June 2004 18:54
| To: glasgow-haskell-users at haskell.org
| Subject: Space usage
| Hi all,
| My intuition tells me that the code in
| should have the same space usage regardless of whether USESMEM is
| defined. However, when compiling with
| ghc -Wall -O2 -cpp --make Mem -o mem
| and running
| ./mem True 100000 > /dev/null
| it runs in constant space but compiling with
| ghc -Wall -O2 -cpp -DUSESMEM --make Mem -o mem
| and running in the same way it increases up to >100M.
| Is this an instance of GHC not being as smart as it could?
| Or is it a case in which I need to give it additional strictness
| annotations in order to get it to run in constant space (and if so,
| what annotations would be best?)?
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users