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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
