> 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 versions. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi