[Swift] Adds new API to reduce memory copying within swift

[mustiikhalil]

Adds new storage container _InternalByteBuffer which will be holding the data that will be created within the swift lib, however reading data will be redirected to ByteBuffer, which should be able to handle all types of data that swift provide without the need to copy the data itself. This is due to holding a reference to the data.

• Adds _InternalByteBuffer which is responsible for creating FlatBuffers
• Moves the current implementation of ByteBuffer to be the external face of the library and allows different ways of initialization
• Removed unowned from the initializer
• Replaces assumingMemoryBinding with bindMemory which is safer
• Adds function that provides access to a UnsafeBufferPointer for scalars and NativeStructs within swift
• Updates docs

[mustiikhalil]

@wtholliday would be nice to have a secondary pair of eyes on the swift implementation, the benchmarks are good when we are creating a buffer. however as mentioned before, reading data from the buffer is a bit slower

[mustiikhalil]

Hello,

@abandy, @mr-swifter. We are currently reworking the way Flatbuffers swift reads data from a data object, what we used to do is make a copy of the data that is stored somewhere and then read from our internal storage, but that seemed to be inefficient. So we decided to refactor that and basically store that data within the ByteBuffer, and provide ways for our already written methods to read from that ByteBuffer, this refactor would allowed us to remove the allowReadingUnalignedBuffers if used correctly.

Questions

• Would this still work with the unaligned data that you provide the ByteBuffer?
• Can we test it to verify that everything works?
• Are you always sure that the first four bytes are the offset of the root/prefix?

Clarification

So in the following test, we are creating an array of bytes that we unalign using a byte at the start and then advancing the pointer, however that advance would always advance into 48, 0, 0, 0, which is the first required offset to read the Monster object

    let testUnaligned: () -> Bool = {
      var bytes: [UInt8] = [0x00]
      bytes.append(contentsOf: fbb.sizedByteArray)
      return bytes.withUnsafeMutableBytes { ptr in
        guard var baseAddress = ptr.baseAddress else {
          XCTFail("Base pointer is not defined")
          return false
        }
        baseAddress = baseAddress.advanced(by: 1)
        let unlignedPtr = UnsafeMutableRawPointer(baseAddress)
        var bytes = ByteBuffer(
          assumingMemoryBound: unlignedPtr,
          capacity: ptr.count - 1)
        var monster: Monster = getRoot(byteBuffer: &bytes)
        self.readFlatbufferMonster(monster: &monster)
        return true
      }
    }

So as long as the bytes within a Data, Uint8 array or even a pointer is pointing to an offset, which in theory is the 48, 0, 0, 0 and not 0, 48, 0, 0 we are all good.

Where do we go from here?

• Revert the changes for allowReadingUnalignedBuffers, which is still a problem if you are reading strings and arrays.
• Adopting the verifier to verify that the data is an unaligned valid Flatbuffer object before trying to read it

[abandy]

Hi @mustiikhalil,

I commented on the Swift Arrow issue you opened and am pasting the reply here as well. Thanks again!

Nice, good to remove unnecessary copying! I will try to pull your changes down and run the tests by end of next week. Even if these changes cause an issue, Swift Arrow should be fine as it is bound to a version of the flatbuffers, so checking in your changes shouldn't break Swift Arrow right away. Thanks for checking!