FPS, ForeignPtr and GHC 6.6
bulat.ziganshin at gmail.com
Fri Apr 21 08:53:42 EDT 2006
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.
= 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# ? :)
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Libraries