Skip to content

runtime: expand capacity of map by more than 1 at a time? #56182

Open
@lizthegrey

Description

@lizthegrey

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Performance

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions