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
Rather than naively making a slice of capacity 2*c+n,
rely on the append(..., make(...)) pattern to allocate a
slice that aligns up to the closest size class.
Performance:
name old time/op new time/op delta
BufferWriteBlock/N4096 3.03µs ± 6% 2.04µs ± 6% -32.60% (p=0.000 n=10+10)
BufferWriteBlock/N65536 47.8µs ± 6% 28.1µs ± 2% -41.32% (p=0.000 n=9+8)
BufferWriteBlock/N1048576 844µs ± 7% 510µs ± 5% -39.59% (p=0.000 n=8+9)
name old alloc/op new alloc/op delta
BufferWriteBlock/N4096 12.3kB ± 0% 7.2kB ± 0% -41.67% (p=0.000 n=10+10)
BufferWriteBlock/N65536 258kB ± 0% 130kB ± 0% -49.60% (p=0.000 n=10+10)
BufferWriteBlock/N1048576 4.19MB ± 0% 2.10MB ± 0% -49.98% (p=0.000 n=10+8)
name old allocs/op new allocs/op delta
BufferWriteBlock/N4096 3.00 ± 0% 3.00 ± 0% ~ (all equal)
BufferWriteBlock/N65536 7.00 ± 0% 7.00 ± 0% ~ (all equal)
BufferWriteBlock/N1048576 11.0 ± 0% 11.0 ± 0% ~ (all equal)
The performance is faster since the growth rate is capped at 2x,
while previously it could grow by amounts potentially much greater than 2x,
leading to significant amounts of memory waste and extra copying.
Credit goes to Martin Möhrmann for suggesting the
append(b, make([]T, n)...) pattern.
Fixes#42984
Updates #51462
Change-Id: I7b23f75dddbf53f8b8b93485bb1a1fff9649b96b
Reviewed-on: https://go-review.googlesource.com/c/go/+/349994
Trust: Joseph Tsai <[email protected]>
Trust: Josh Bleecher Snyder <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Josh Bleecher Snyder <[email protected]>
0 commit comments