[ oops, I meant to send this yesterday but it didn't go out for some
reason ]
On 18 October 2005 12:40, Krasimir Angelov wrote:
> ForeignPtr requires more memory. Each ForeignPtr has
> ForeignPtrContents structure attached. In the ForeignPtrContents there
> is one IORef. Each finalizer adds one Weak# object in the heap. The
> IORef is a reference to a list of finalizers, so each new finalizer
> adds a new CONS cell. The finalizers require additional steps in GC
> time. I haven't tried to measure the difference between ForeignPtr and
> ByteArray# based implementations but it seems to me that the latter
> might be better. Of course it will be GHC specific.
> mmap is valuable only for large string. Typically only when someone
> wants to read the entire file in the memory. For this case a special
> data structure might be provided.
We can assume that in the packed string case, most of the packed strings
will be allocated in Haskell, and will therefore be represented by a
ForeignPtr with a ByteArray# inside - therefore no finalizer, no Weak#
object, and no cons cells.
It is a shame that we need the IORef, but I'm wondering whether we
should have a special kind of ForeignPtr to which you can't add any more
finalizers (ie. addForeignPtrFinalizer would fail) to optimise this
case. We never need to add any finalizers to packed strings created in
Haskell. Also, the IORefs will interact badly with generational GC, so
we should really get rid of them.
If we eliminated the IORef, then the difference between ByteArray and
ForeignPtr would be one word, i.e. negligible. I think the flexibility
is worth it. Also, I bet that you won't find any useful benchmarks in
which the difference is significant
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
