[Haskell-cafe] uvector package appendU: memory leak?

Claus Reinke claus.reinke at talk21.com
Sun Mar 29 18:54:04 EDT 2009


> But Claus was right, appendU is lazy; this seems to be the cause of the 
> problem.

appendU is strict, insertWith just doesn't force it (follow the source link
in the haddocks to see why).

> However now I don't really understand why the two implementations 
> differs in lazyness.
> 
> Or, to ask a different question, how can I make the version using 
> insertWith strict?

deja vu:-(
http://www.haskell.org/pipermail/haskell-cafe/2009-March/057032.html

As you've noticed, alter also allows to enforce strictness.

But piling up appendUs is still not a good idea. For a moment,
I thought that the stream representation's (+++) was handling
runtime fusion gracefully, but a simple test case suggests otherwise
at least for the simpler case of consU (the attached appendU.hs
doesn't do any appendUs, as the consU case already demonstrates
the issue; be careful with large numbers here, it'll quickly eat your ram):

The test is a silly loop, using consU a lot (which isn't uvectors main 
target), to copy an array. The difference between the plain loop and
the unfolded loop shows that compile-time fusion can improve this,
suggesting that no runtime fusion is taking place. The simulated
runtime fusion version demonstrates (by staying within lists till the
end, only then switching back to arrays, avoiding all the intermediate
partial array copies). The old bytesting cons thread I linked to was
about integrating real runtime fusion into things like bytestring/uvector.

Claus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: appendU.hs
Type: application/octet-stream
Size: 1366 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090329/b639e511/appendU.obj


More information about the Haskell-Cafe mailing list