Question about base/containers/README.md

[Erik Chen]

Hi cxx,

The current text in base/containers/README.md suggests that absl maps should be used, and std maps should not be used. We discussed this in TSC (cc-ed a couple folks) and were a bit surprised to see this. Has there been a cost-benefit analysis or email thread or other documentation about this?

[Alex Cooper]

FYI there is a related discussion on this thread about hte container types as well: https://groups.google.com/u/1/a/chromium.org/g/cxx/c/ZAnUcGV3G0Q

On Wed, Feb 11, 2026 at 4:08 PM Erik Chen <erik...@chromium.org> wrote:

Hi cxx,

The current text in base/containers/README.md suggests that absl maps should be used, and std maps should not be used. We discussed this in TSC (cc-ed a couple folks) and were a bit surprised to see this. Has there been a cost-benefit analysis or email thread or other documentation about this?

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAEYHnr2yhaDvtfujFjwSwqKsDu569y3siU%3D2AHoggjrawhDSLQ%40mail.gmail.com.

[Joe Mason]

The Catan team did an investigation of absl maps performance at the end of last year. TLDR: compared to std::map, absl::flat_hash_map doesn't have WORSE performance overall, and has better peak memory usage. Compared to base::flat_map, it has fewer footguns. So we recommend using it as the default, but it's not enough of an improvement to migrate any existing maps unless they're known have performance issues.

We migrated the highest-contention maps that we found through profiling and did an A/B comparison. (mojo::ReceiverSetState, BinderMapWithContext, SubprocessMetricsProvider, and resource_attribution::QueryBuilder, which happened to all be std::maps that didn't depend on ordering.) The result was a clear improvement to the 99th %ile of PMF, but no significant change to any guiding performance metrics. (Google-internal metrics results: https://uma.googleplex.com/p/chrome/variations?sid=97b871ee9955318d4582fc1a247bde03)

Micro-timing metrics were inconsistent. eg. Navigation.RenderFrameHostConstructor / Navigation.RenderFrameHostDestructor measure the time to create/destroy RenderFrameHosts, which contain 2 of those important maps. The constructor was about 0.1% faster on some platforms, about 0.1% slower on others, with the destructor showing the opposite. My conclusion (backed up by digging into CPU profiles) is this is caused by different memory allocation strategies: absl::flat_hash_map, like vector, allocates a slab of memory up front, while std::map stores a tree of pointers and has many small allocations. Platform differences depend on the allocator implementation.

The timing of resource_attribution::QueryBuilder actually regressed, because it uses a highly unoptimal pattern: it repeatedly builds small maps, merges them into a large map, then throws them away. That was a poor pattern with std::map too, but absl::flat_hash_map makes it worse. I have a bug assigned to me to optimize it. It's unlikely that random map usages will hit this degenerate allocation pattern - certainly more unlikely than that they'll hit the O(n) complexity of repeatedly updating a base::flat_map.

I think the decision to recommend absl::flat_hash_map was mostly driven by the poor ergonomics of base::flat_map, not benchmarks. Our experiment showed that a mass conversion likely won't regress anything but also won't show major gains.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAGOLbz1g5794iYTn1VVkyGvj%3DfaJetsgc16_amc%3D44LzVE2B%2BQ%40mail.gmail.com.