Using UnsafeMutablePointer instead of UnsafeMutableBufferPointer to overhead space overhead with Optionals?

Using Swift
1

Hello, I’m writing a custom String type that operates like Rust’s std::string::String (so ~Copyable).

In Rust, Vec uses a NonNull<T>, which is equivalent to a non-optional non-Buffer pointer in Swift. In the 0 capacity case, rather than null, the pointer is initialised to the alignment of T, which allows an Option<Vec<_>> to be 24 bytes.

My UniqueString type has so far used a UnsafeMutablePointer<UInt8> as its storage, and in init(), it is initialised to .init(bitPattern: 0x8)!. This allows UniqueString? to also be 24 bytes, but I want to start using UnsafeMutableBufferPointer for QoL, and because baseAddress is optional, I would lose that optimisation. What should I do here? I have considered just having a property:

var bufferPointer: UnsafeMutableBufferPointer<UInt8> {
   .init(start: _pointer, count: _count)
}

…but this seems silly.

2

Are you already storing the length of the string in another field? Then yes, the buffer pointer is redundant and you can just store the base pointer; if you later need a buffer pointer, reconstituting one is trivial.

So you're aware, the sizes of Optional<UnsafeMutablePointer<UInt8>> and UnsafeMutablePointer<UInt8> are the same; the .none case is bitwise-equal to the null pointer, so no extra storage is required for it.

1 Like
3

Yes, I store:

struct UniqueString {
   var _pointer: UnsafeMutableBufferPointer<UInt8>,
       _count: Int,
       _capacity: Int
}

But to make copying between different pointers more convenient, I sort of want to fold _capacity into _pointer by using a buffer pointer.

Yes, but unfortunately since UnsafeMutableBufferPointer.baseAddress can be nil, folding _capacity into _pointer would increase the size of UniqueString?.

EDIT: Added missing ? to last sentence - UniqueString → UniqueString?

5

Sorry, I must be missing something. UnsafeMutableBufferPointer is two words long and contains a base address and a count (which in this context is its capacity). If the base address is nil, the count must be 0. So for the case of an unallocated string, it has zero capacity by definition.

It shouldn't be necessary to "pack" the capacity into the buffer as it's already stored there.

6

Perhaps I worded it badly. By ‘packing _capacity into _pointer', I mean switching to a UnsafeMutableBufferPointer and removing _capacity.

7

Which would not increase the size of the structure.

8

But it would increase the size of UniqueString?, which seems avoidable, but I then can’t use BufferPointer

9 
struct MyString: ~Copyable {
  /// The buffer containing the string. Its `count` property equals the string's capacity.
  private var _buffer: UnsafeMutableBufferPointer<CChar>

  /// The number of characters in the buffer that have been initialized.
  private var _count: Int

  /// The maximum number of characters in the buffer before needing to reallocate it.
  private var _capacity: Int {
    get {
      _buffer.count
    }
    set {
      fatalError("FIXME: implement buffer resizing here as needed")
    }
  }

  init() {
    _buffer = .init(baseAddress: nil, count: 0)
    _count = 0
  }

  deinit {
    _buffer.deallocate()
  }
}

The size of this structure is 24 bytes on 64-bit systems (12 bytes on 32-bit systems).

10

They're asking about the size of an optional value of their type, not just the type itself.

If they use UnsafeMutablePointer and track capacity separately, then they get this property:

struct MyString: ~Copyable {
  private var _buffer: UnsafeMutablePointer<CChar>
  private var _count: Int
  private var _capacity: Int

  init() {
    _buffer = UnsafeMutablePointer<CChar>.allocate(capacity: 1)
    _count = 0
    _capacity = 0
  }
}

print(MemoryLayout<MyString>.size)  // 24
print(MemoryLayout<MyString?>.size)  // also 24!

Based on the generated code, the compiler is recognizing that since the first property is a non-optional pointer, there's no valid all-zeros bit pattern for a MyString and it can use that as the value for nil as MyString? instead.

// func f() -> MyString? { return nil }

output.f() -> output.MyString?:            # @"output.f() -> output.MyString?"
        push    rbp
        mov     rbp, rsp
        xor     eax, eax
        mov     ecx, eax
        mov     rax, rcx
        mov     rdx, rcx
        pop     rbp
        ret

Your type that uses UnsafeMutableBufferPointer, on the other hand, has this outcome:

print(MemoryLayout<MyString>.size)  // 24
print(MemoryLayout<MyString?>.size)  // 25

The compiler can't do the same packing because all-zero is a valid UnsafeMutableBufferPointer.

IMO, this isn't silly at all; it provides convenient access when you need it, but you're optimizing the layout specifically for the nil case to make it fit within the same bit width as a non-nil value. This is just the kind of trick you have to use sometimes when you're doing low-level work.

4 Likes
11

They're asking about the size of an optional value of their type, not just the type itself.

Exactly, although I don't allocate in the case of the empty string, and initialise the pointer to 0x08 (like Rust's String which uses NonNull::dangling)

IMO, this isn't silly at all;

Good to hear, thank you!