alastair at reid-consulting-uk.ltd.uk
Wed Mar 19 12:23:24 EST 2003
> This is all fine, except that implementing finalizer ordering slows
> down ForeignPtrs quite a bit, in particular mallocForeignPtr takes a
> 20% hit just allocating the IORef needed to store the list of
> finalizers. Ideas for a better implementation are welcome.
Having obviously optimized the hell out of mallocForeignPtr, it sounds
like it's time to optimize the hell out of IORef. :-)
Or, on the assumption that the slowdown comes from splitting what was
a single object into 2 or even three separate objects, do what it
takes to turn it back into a single object - i.e., put a mutable
field directly in the MFP object.
Best of all, do as CAML has done and add the machinery (and semantics
changes) necessary so that whenever you have a tuple with a mutable
field in it, GHC will implement it without adding an indirection
through a separate IORef object. Highly worthwhile and might possibly
help with your MFP problem :-)
> Anyway, this message is really about what names we should use for
> the old Haskell-finalizer versions of newForeignPtr and
> addForeignPtrFinalizer (and as such it doesn't have any bearing on
> the FFI spec 1.0).
I'm rather taken by 'oldNewForeignPtr'.
> I'm assuming that we want to keep these functions in some form in
> GHC - where to put them is one issue; Foreign.ForeignPtr is a
> possibility (but not ForeignPtr), or GHC.ForeignPtr.
I'd put them in GHC.ForeignPtr and make no other change in their name.
Easy for people to transition, easy for people to see non-portable
code, probably little risk of collision with the ffi-mandated FunPtr
Alastair Reid alastair at reid-consulting-uk.ltd.uk
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
More information about the FFI