{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigmaefwybyaa5cbxwj7r27ogo2q6cbkx7s6c7dvufd2tgg7putsmm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkjddhjhx7t2"
  },
  "path": "/t/could-collections-hypothetically-store-keys-and-values-inline/24195#post_11",
  "publishedAt": "2026-04-27T23:42:17.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I also think that the stdlib making the promise was wrong, but for a different reason – it precludes optimisations as a result of, e.g., getting the collection types to cooperate more closely with the allocator.\n\nFor example, storing the capacity in `Vec` seems like double-storing to me. Most modern allocators are a combination of a slab allocator for small allocations, and a buddy allocator for large allocations (split up variously between the runtime libraries and operating system); all the high-performance allocator designs I've looked at recently seem to be converging on that design. For a slab allocator, allocations that have similar addresses have the same size, so it is more efficient to store the allocation size (= capacity) once per page rather than once per allocation. Buddy allocators might theoretically benefit from storing the size separately, but for large allocaitons, getting the allocator to track the size is beneficial because it doesn't have to do it very often.\n\nIn cases where the program has control over its virtual memory layout (which I think is true on Linux/Windows/Mac OS, although not always on embedded platforms), and where the virtual address space is much larger than the physical address space (true on most 64-bit platforms with virtual memory), you can go even further and just embed the capacity directly into bits of the pointer by allocating it an appropriate address. This makes reading the capacity potentially faster than with the pointer/capacity/length layout, because you don't actually have to read the capacity from memory, just use a few masks and shifts.\n\n(This discussion got me thinking about other things, like \"so what if you get the allocator to always allocate at addresses which aren't valid UTF-8?\" – I decided that this wouldn't be costly to do on 64-bit platforms but probably wouldn't be very helpful for efficient strings.)\n\nIn any case, it seems wrong to me to preclude potential optimisations like `Vec` and `String` have done; some may be good ideas and some may be bad ideas, but it is very likely that at least some might be beneficial.",
  "title": "Could collections hypothetically store keys and values inline?"
}