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

[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