Bertram Felgenhauer <bertram.felgenhauer <at> googlemail.com> writes:
> > Hi Will, > > Will Ness wrote: > > addition: with > > gaps k xs = minus [k,k+2..] xs > > it also runs without the space leak, but with > > gaps k = minus [k,k+2..] > > the leak reappears. > > I'm not sure that I tried the same code as you did, but for me both > these versions were leaky. I cannot explain why, but I see that in the > resulting core (ghc ... -ddump-simpl) the [5,7..] list ends up as a top > level constant, despite -fno-full-laziness. So the cause of the space > leak remains the same -- the [5,7..] list is being shared among several > invocations of g. Tricky. > > Bertram > Hi, I've ended up with primes = 2 : g (fix g) where g xs = 3 : gaps 5 (unionAll [[x*x, x*x+2*x..] | x <- xs]) Here's the test entry: https://ideone.com/qpnqe The both "gaps" leak (25MB for 500k run) if "fix" is made internal function and there's no -fno-cse switch. But with the switch, one stops leaking, and the other goes to 120MB. Tricky, one could say, is an understatement. :) I wish (avoidable) space leaks could/would be considered a "bug" and compiler would find ways to avoid it, all by itself (or with a super-switch, "-fno- leaks" say). Then we'd needn't worry about such things, and could just write such "mythical one-liners" with confidence. :) Cheers, and thanks a lot, Will _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
