FPS, ForeignPtr and GHC 6.6

[Bulat Ziganshin]

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 at gmail.com