Can I close this ticket as not being to do with uvector? -- Don manlio_perillo:
Claus Reinke ha scritto:
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).
Ok, I see. But, IMHO, this should be clearly documented.
I have updated my test code: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3103
The interesting thing is that using appendU is *faster*.
Using appendU: real 0m38.736s user 0m38.638s sys 0m0.048s
Using snocU: real 0m41.279s user 0m40.939s sys 0m0.040s
Memory usage is the same.
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
Your are right, sorry. The problem is that at that time I was not able to fully understand the code!
However, reading the code now, I prefer my version using alter.
By the way, about insertWith/alter; from IntMap documentation:
insertWithKey: O(min(n,W) alter: O(log n)
So, alter is more efficient than insertWithKey? And what is that `W` ?
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):
I'm not sure to fully understand the code. But, again, IMHO it does not apply to my original problem.
[...]
Thanks Manlio