This is what you're describing, right? https://play.golang.org/p/RJbEkmFsPKM
The code that does this is here https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242 . Note that there are cap adjustments to optimise block sizes and alignments. This explains why we see what we do. On Sat, 2021-09-04 at 20:57 -0700, tapi...@gmail.com wrote: > > > On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader > wrote: > > On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com <tapi...@gmail.com > > > wrote: > > > The problem of the current algorithm is it is not monotonically > > > increasing: > > > > > > > Please explain why that is a problem. Also, I think you are > > misusing "monotonically increasing". The behavior up to length 1024 > > is not "monotonically increasing". It is exponential growth. > > > > I mean the whole length range. Why would you seect [0, 1023]? > I never deny it is exponential growth. > > > > > > 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: > > > > > > > Again, please explain why this is a problem. > > > > When I merge two slices, I expect the argument orders are not > important. > > > > > > 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...@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 > > > . > > > > -- 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/10393e5ca795593dece41075042ae0f3b7c6863a.camel%40kortschak.io.