#3273: memory leak due to optimisation
-----------------------------------------+----------------------------------
Reporter: sebf | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-----------------------------------------+----------------------------------
Comment (by int-e):
It's a rather more interesting case than #917 - only the first 10k
elements of the list {{{[1..]}}} are evaluated, which don't account for
the huge memory blowup that we observed.
I've looked at the core for {{{condensed.hs}}}. Basically what happens is
that {{{plus}}} gets turned into
{{{
plus a b = S (\c -> let unSac = unS a c
unSbc = unS b c
in \d -> if d==0 then []
else unSac (d-1) ++
unSbc (d-1))
}}}
and {{{runS}}} gets turned into
{{{
runS a = let runa = run a in concatMap runa [10000]
}}}
With these two changes the program blows up even without optimizations.
It's still quite amazing to me, but apparently there is just enough
explicit sharing to hold onto the complete {{{natSum}}} computation in
some form.
I'm curious how the ''id'' functions affect this - maybe they influence
arity analysis and that in turn has an effect on the candidates for
floating out?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3273#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
