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.

Reply via email to