Description
Follow-on to #52157 and #54454
Right now the reference code in /x/exp/maps.Copy will potentially call runtime.growWork_faststr
and runtime.hashGrow
many times if src
and dst
are mostly disjoint and len(src)
is large.
There should be some smarter logic to be able to not just pre-allocate a map with a certain capacity at creation time, but to expand an existing map by a certain amount (e.g. by len(src)
) -- there already exists this idea with variadic append()
for concatenating slices.
Short of that, maybe Copy() should make a decision based on the sizes of dst
and src
& capacities available in dst
on whether it's more efficient to create a new map with capacity = len(src)+len(dst)
and then copy dst and src both into the new map.
(you could then Shrink() the map if you were confident it were going to be read-only after that, to avoid overshooting usage by too much)
The real-world pain here is that telemetry libraries like OpenTelemetry and Honeycomb Beelines like to keep maps of attributes associated with a given trace span, and merge them together before sending into a final map; a lot of work is done to growWork_faststr and hashGrow if many attributes are added one at a time if map merging/copying via iteration.
Parallels in other languages: Rust