append is a bit inefficient when bytestrings are short

[treeowl]

append unconditionally uses FFI calls to memcpy for both bytestrings. If one or both of them are known at compile time to be very short, this is inefficient. I believe there's a very simple solution: just use GHC primops to do the copying instead of FFI. When there's a known short length to copy, instructions will be emitted to copy directly; otherwise the compiler will use an FFI call. No need to do this so manually.

[sjakobi]

Thanks for the tip! Which is the primop that we should use?

[treeowl]

copyAddrToByteArray# looks like the right one to me. Note that this is only optimized when the number of bytes to be copied ends up being a CMM literal. I don't know just what it takes to make sure that happens, but it's a much better bet than not even trying, and allows any potential future improvements in GHC's implementation to help further.

[Bodigrim]

I'm not sure how copyAddrToByteArray# would help. There is no immediate ByteArray here.

[treeowl]

@Bodigrim It requires a bit of extra work, pulling in GHC.ForeignPtr. Instead of using the stock mallocPlainForeignPtrBytes, we can build the ForeignPtr ourselves, filling a ByteArray# and then wrapping it up. Rough sketch:

blargh :: Int -- ^ size of string to create
  -> (MBA RealWorld -> IO ())  -- ^ how to mutate it
  -> IO (ForeignPtr a)
blargh (I# size) builder = IO $ \s ->
    case newPinnedByteArray# size s     of { (# s', mbarr# #) ->
    case unIO (builder (MBA mbarr#)) s' of { (# s'', ~() #) ->
       (# s'', ForeignPtr (byteArrayContents# (unsafeCoerce# mbarr#))
                         (PlainPtr mbarr#) #)
     }}
{-# INLINE blargh #-}

The argument to blargh is the copying code, which has access to the MutableByteArray#.

[Bodigrim]

Yeah, but I'm not convinced that an overhead for allocating redundant ByteArray header does not absorb potential savings from unrolled copyAddrToByteArray#.

[treeowl]

@Bodigrim what redundant ByteArray header? The MBA wrapper will inline away. If you don't trust that, you can use MutableByteArray# RealWorld -> IO () instead, but I'm pretty sure that's not necessary.

[treeowl]

The point is not the exact details; it's that if we crack open GHC.ForeignPtr we can get our hands on the MutableByteArray# before it's wrapped in its ForeignPtr and have our way with it.

Side note: it is odd that I can't find a copyAddrToAddr# primop. Does it go by another name, or does it really not exist?

[Bodigrim]

Sorry, I meant ByteArray# header, which is memory until byteArrayContents#: header and array size, already 16 bytes.

[treeowl]

OK, but that's not extra. We get that already by calling mallocPlainForeignPtrBytes! My blargh is just mallocPlainForeignPtrBytes with a callback. I also removed a safety check, but that probably should actually remain in case of enormous arguments whose sum overflows.