I agree with SimonM that the proposed routines have useful
applications. Furthermore, it is trivial for Haskell
systems to implement these routines. Hence, I will include
them into the spec unless there are serious objections.
Cheers,
Manuel
___
FFI
Nevertheless, I think even without the tricks I'm using in GHC, the
case where a ForeignPtr is used in conjunction with malloc()/free()
is one which is likely to be optimisable in any system with its own
memory management.
I wasn't meaning so much that only GHC could take advantage of it
[...] using a ForeignPtr here, with free() as its finalizer, adds so
much overhead that [...]
Where is the overhead coming from? Is it the cost of a C call or the
cost of the standard malloc library?
It's the combined cost of
- malloc()
- creating a weak pointer to register the
Simon Marlow [EMAIL PROTECTED] wrote,
I'd like to propose two new functions for the ForeignPtr interface:
mallocForeignPtr :: Storable a = IO (ForeignPtr a)
mallocForeignPtrBytes :: Int - IO (ForeignPtr a)
(the names can change, of course). The implementations are
I vaguely remeber that in the context of the withForeignPtr
discussion we where once trying to achieve some similar
effect (but couldn't come up with something that would
work). Do you remember?
Uh, my memory's a bit vague too :-)
For a long time we were trying to get cheap
Can you achieve the same performance gain by adding some rewrite rules?
--
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Can you achieve the same performance gain by adding some
rewrite rules?
Perhaps you could try to spot
(=) malloc (\p - newForeignPtr p free)
Hmmm. Actually I'd like to do both: add the functions, because they
encapsulate a common case and guarantee a speed improvement if you use
