Thanks for the responses.

This is basically what I've got looks like (grossly simplified):


data Monad m => Foo m a b =
     Foo
     { action :: m (Foo m a b, b)
     , update :: a -> Foo m a b
     }

The driver loop injects new values with update, and executes action whenever it's ready to, replacing the old Foo with the newly returned Foo.

I finally fixed the space leak it by inserting SPECIALIZE pragmas for Foo IO a b on every function that creates a Foo. I'm not sure if I can remove all the strictness annotations I've accumulated yet, though. This is a bit disconcerting, though, because in the future I'd like to not use IO and use a strict State instead. I hope I won't have to specialize for every monad that ends up getting used.

Thanks again,
Pete


Jefferson Heard wrote:
Peter, from 500 feet, we can't see much, but your strictness might
actually be your problem depending on what "largish" looks like and
whether you're reading your data from disc.  It's entirely possible
that your data structure updates or disc reads are head-strict and
you're evaluating or loading the entirety of data in memory at a
single update.

-- Jeff

On Thu, Jul 17, 2008 at 2:58 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
On Thu, Jul 17, 2008 at 12:14 PM, Peter Gavin <[EMAIL PROTECTED]> wrote:
Hello everyone,

I have this piece of code I've been working on, and I've been stuck on
tracking down a space leak in it for some time now.  The code is essentially
a tight loop that updates a rather largish data structure with embedded
functions that are called by the driver loop.  The code doesn't accumulate
any data as the loop runs (at least deliberately), so I would expect the
memory profile to be flat.  Unfortunately, the profile is a wedge :)   I've
added bangs and `seq` literally everywhere, and it looks (to me at least)
like there's nothing left to be lazily evaluated anywhere.  I've used
retainer profiling, and the functions that are leaking space according to
the profiler output are strict throughout.
I don't know what I can suggest as for general tactics.  Without
seeing the code it's hard to say what could be happening.  Just
remember that strictness is not always the answer!

>From the very limited amount of information I got from this
description, my first guess would be the data structure itself, or the
functions inside it.  If it's lazily generated, then you might not be
seeing the full amount of space it's taking up at once.  But that's
just a guess.

Luke
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to