Editing Memory leak (section)

== Types of leaks ==

=== Holding a reference for a too long time ===

Consider for example:
<haskell>
let xs = [1..1000000::Integer]
in  sum xs * product xs
</haskell>
Since most Haskell compilers expect that the programmer used <hask>let</hask> in order to share <hask>xs</hask> between the call of <hask>sum</hask> and the call of <hask>product</hask>,
the list <hask>xs</hask> is completely materialized and held in memory.
However, the list <hask>xs</hask> is very cheap to compute, and thus memory usage can be reduced considerably by computing <hask>xs</hask> in each call.

To achieve this while avoiding code duplication, we can turn the list definition into a function with a dummy argument.
<haskell>
let makeXs n = [1..n::Integer]
in  sum (makeXs 1000000) * product (makeXs 1000000)
</haskell>

=== Building up unevaluated expressions ===

Another typical cause of memory leaks are unevaluated expressions,
the classical example being to sum up the numbers of a list (known as <hask>sum</hask> function).
<haskell>
foldl (+) 0 [1..1000000::Integer]
</haskell>
The problem is, that the runtime system does not know, whether the intermediate sums are actually needed at a later point,
and thus it leaves them unevaluated.
I.e. it stores something equivalent to <hask>1+2+3+4</hask> instead of just <hask>10</hask>.
You may be lucky that the [[strictness analyzer]] already removes the laziness at compile time,
but in general you cannot rely on it.
The safe way is to use [[seq]] to force evaluation of intermediate sums.
This is done by <hask>foldl'</hask>.
<haskell>
foldl' (+) 0 [1..1000000::Integer]
</haskell>

=== Keeping not needed references alive ===

Consider the following definition:

<haskell>
x = fst (a, b)
</haskell>

Until we evaluate <hask>x</hask>, both references <hask>a</hask> and <hask>b</hask> are kept alive.

After evaluating <hask>x</hask>, <hask>b</hask> can be garbage collected if <hask>b</hask> is not referenced elsewhere.