You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal here is to reduce excessive time spent growing slices and maps.
The idea would be to track slice/map declaration/allocation sites (by PC, perhaps including N frames of caller context for additional precision) and the typical (approximate median?) maximum size of containers from that allocation site. Future allocations would use the median to allocate the expected size up front, thus avoid grow work.
Some thoughts from initial discussions:
Perhaps rather than tracking allocation sites, we track grow sites. Containers would still need to grow once, but we'd expect the first growth to jump up to the expected maximum size.
Slice allocations that specify a capacity likely need to skip this optimization in order to maintain compatibility. IMO, this is a good idea anyway, as it provides as way for authors to specify a precise capacity when they know more precisely than the median (e.g., a capacity based on the length of another slice, such as in cmd/compile: pre-allocate a slice of provable length #64595).