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