The problem of the current algorithm is it is not monotonically increasing:
x1 := make([]int, 897)
x2 := make([]int, 1024)
y := make([]int, 100)
println(cap(append(x1, y...))) // 2048
println(cap(append(x2, y...))) // 1280
And it is not symmetrical:
x := make([]int, 98)
y := make([]int, 666)
println(cap(append(x, y...))) // 768
println(cap(append(y, x...))) // 1360
And it depends on the capacity of the first argument,
which is some logical but often not for many cases:
x := make([]byte, 100, 500)
y := make([]byte, 500)
println(cap(append(x, y...))) // 1024
println(cap(append(x[:len(x):len(x)], y...))) // 640
On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:
> Hey Guys,
>
> We know slices grow by doubling until size 1024, the capacity will grow at
> 25%. The question that I had was why after 1024 elements? Why didn't the
> developers chose another number like 2048 or other numbers?
>
> Thanks,
> Milad
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com.
