Safe Haskell | None |
---|---|
Language | Haskell2010 |
In rare occasions GHC optimizes innocent looking loops into space-leaking monsters. See the discussion here: GHC issue 13080 for more details, or this blog post about space leaks in nested loops
These functions in this module might help, at least in conjunction with
the -fno-full-laziness
GHC option.
There is a unit test in the sources of this module, which can be used to do a
comperative heap profiling of these function vs. their counterparts in the
base
package.
Here are the images of the profiling results, the images show that the
functions in this module do not leak space, compared to the original functions
(forever
and replicateM_
):
Since: extensible-effects-concurrent-0.4.0.0
Synopsis
- foreverCheap :: Monad m => m a -> m ()
- replicateCheapM_ :: Monad m => Int -> m a -> m ()
Documentation
foreverCheap :: Monad m => m a -> m () Source #
A version of forever
that hopefully tricks
GHC into not creating a space leak.
The intuition is, that we want to do something that is cheap, and hence
should be recomputed instead of shared.
Since: extensible-effects-concurrent-0.4.0.0
replicateCheapM_ :: Monad m => Int -> m a -> m () Source #
A version of replicateM_
that hopefully tricks
GHC into not creating a space leak.
The intuition is, that we want to do something that is cheap, and hence
should be recomputed instead of shared.
Since: extensible-effects-concurrent-0.4.0.0