{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie3bas7jggs6ta7mgbpouef5qglzeonwyggk2en5fonplgdz6cll4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkpdqwbcrrj2"
  },
  "path": "/t/could-collections-hypothetically-store-keys-and-values-inline/24195#post_13",
  "publishedAt": "2026-04-30T08:43:24.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "In my experience, having a large number of small hash maps is very rare—in part because a hash map is a bad implementation for tiny sets/maps anyway (faster to do linear search over an array than hash stuff).\n\nBy comparison, \"a bunch of short strings\" is a common use case. I think it is reasonable to say that if the Rust standard library is willing to give up small string optimizations for pointer stability guarantees, giving up a purely hypothetical[1] small hashmap optimization is also worth it.\n\nEven if you take the position that making this choice with `String` was a mistake (which I find to be a relatively compelling case), that choice has been made and having the same consistency and guarantees in other places at negligible sacrifice seems to make sense to me.\n\n* * *\n\n  1. To my knowledge, nobody has bothered to implement this: `compact_str` exists, `compact_map` does not, to my knowledge. This is not an optimization C++ bothers to make, nor is it an optimization that Google's C++ hashmap implementation which Hashbrown is based off makes afaik. If you are aware of _any_ case—in any language—where somebody actually does a small hashmap optimization like this, I would be curious to see it. ↩︎\n\n\n",
  "title": "Could collections hypothetically store keys and values inline?"
}