I think that adding the extra check to see if the pointers are identical sped this up enough that it's probably no longer a major issue--I'm pretty certain that the problem was large strings that were identical, so every byte had to be checked, so probably scary non-portable home-made ForeignPtrs would not be worth the effort. (Although I'm somewhat curious as to how it would be done...)

A ForeignPtr allocated with mallocForeignPtr in GHC is heap-allocated garbage-collectable storage, and doesn't need a finalizer. The other kind of ForeignPtr created with newForeignPtr is associated with some external storage and needs a finalizer. Finalizers are expensive, and so is malloc(), but mallocForeignPtr is very cheap. This gives rise to a sum-type in the implementation of ForeignPtr: see the source code (libraries/base/GHC/ForeignPtr.hs). You could make a specialised version by ripping out the non-malloc ForeignPtr bits, and make an unboxable ForeignPtr type. A mallocForeignPtr-style ForeignPtr is essentially the same as an IOUArray. In fact, the underlying implementation type is the same (MutableByteArray#), except that a ForeignPtr is allocated in pinned (immovable) storage so that it can be passed to foreign functions. There could easily be a conversion from a "malloc" ForeignPtr to IOUArray. There is also some overlap with the StorableArray type. A StorableArray has a ForeignPtr inside it. It really looks like the framework could be simplified here, but I remember putting some thought into it and not coming up with a simple solution. Cheers, Simon