Hello Simon, Friday, April 21, 2006, 3:44:17 PM, you wrote:
The point is that you can't implement all the operations in FPS using a ByteArray# representation, so that's a bogus comparison.
that operations can't be implemented with pinned byte arrays? i think only mmap support?
ForeignPtr is the right thing!
they are slower in 6.4 they need more memory memory fragmentation can't be eliminated by GC moreover, implementation of ListLike interface for all arrays is anyway useful. currently proposed ByteString is just one limited implementation of this. why haskellers prefer to implement facilities for just one concrete datatype instead of supporting whole classes?? moreover, Donald made most of its test with excessively large strings. for strings of real size (10-100 bytes) speed difference will be typically the same as in his `wc` test. so the current implementation slows library at least 2 times and this can't be avoided without switching to 6.6
BTW, we could improve the performance of ForeignPtr even further by eliminating the IORef in its representation. This means losing the ordering property of addForeignPtrFinalizer, but if we did this just for the ForeignPtrs created by FPS.pack, I doubt anyone would ever notice, and you save 12 (24) bytes per PS.
data ForeignPtrContents = PlainForeignPtr !(IORef [IO ()]) | MallocPtr (MutableByteArray# RealWorld) !(IORef [IO ()]) you mean adding 3rd variant here: | PlainMallocPtr (MutableByteArray# RealWorld) ? btw, i still wondering - that is the difference between MutableByteArray# and ByteArray# ? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com