Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Arnaud Delobelle]

Nice!

Arnaud

On Tue, 7 Sep 2021, 18:02 Keith Randall,  wrote:

> Sounds good. CL up for review at
> https://go-review.googlesource.com/c/go/+/347917
>
> On Mon, Sep 6, 2021 at 7:30 PM Arnaud Delobelle  wrote:
>
>> If the growing function is currently
>>
>> f(x) = 2x for x < 1024
>> f(x) = x + x/4 otherwise
>>
>> (Which I haven't checked), couldn't a simple way be to use e.g.
>>
>> f(x) = 2xfor x < 1024
>> f(x) = x + x/4 + 768 otherwise
>>
>> Then
>>
>> f(1023) = 2046
>> f(1024) = 2048
>>
>> So the function is monotonic (and kind of "smooth")
>>
>> On Tue, 7 Sep 2021, 02:17 'Keith Randall' via golang-nuts, <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> I don't think this is an important thing to fix, but I agree it is a bit
>>> odd. If there's a simple way to restore monotonicity we'll consider it.
>>> A similar issue: https://github.com/golang/go/issues/41239
>>>
>>> On Sunday, September 5, 2021 at 8:59:01 AM UTC-7 jake...@gmail.com
>>> wrote:
>>>
 You are 100% correct. I missed that value. oops

 On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com
 wrote:

>
>
> On Sun, 5 Sep 2021, 14:59 jake...@gmail.com, 
> wrote:
> [...]
>
>> In the example given  (https://play.golang.org/p/RJbEkmFsPKM
>> ), the capacities *are 
>> *"monotonically
>> increasing", as no number in the second column is smaller than the one
>> before it.
>>
>
> Nitpick: that is not true.  I copy-pasted the output of the playground
> below.
>
> 0 8
> 100 208
> 200 416
> 300 640
> 400 896
> 500 1024
> 600 1280
> 700 1408
> 800 1792
> 900 2048
> 1000 2048
> 1100 1408 <-- at this point the new cap is less than for the previous
> row
> 1200 1536
> 1300 1792
> 1400 1792
> 1500 2048
> 1600 2048
> 1700 2304
> 1800 2304
> 1900 2688
>
> Regards,
>
> Arnaud
>
> On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>>
>>> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
>>> > I'm not sure you're clear about what "monotonically increasing"
>>> > means.
>>> >
>>> > Are you saying that there are some cases where append() results in
>>> > the allocated size of a slice *shrinking*? If so, please
>>> > demonstrate.
>>>
>>> I think he means that the cap of the appended slice is not a
>>> monotonically increasing function of the cap of the input slice.
>>>
>>> https://play.golang.org/p/RJbEkmFsPKM
>>>
>>>
>>> --
>> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/fa360f3d-e23c-4c07-9505-9f89bd155bb8n%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/CAJ6cK1aAonAjO7rd8-wnnVeLAFX4HixFUk7s3hJnEqtwRaz4uA%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Keith Randall' via golang-nuts]

Sounds good. CL up for review at
https://go-review.googlesource.com/c/go/+/347917

On Mon, Sep 6, 2021 at 7:30 PM Arnaud Delobelle  wrote:

> If the growing function is currently
>
> f(x) = 2x for x < 1024
> f(x) = x + x/4 otherwise
>
> (Which I haven't checked), couldn't a simple way be to use e.g.
>
> f(x) = 2xfor x < 1024
> f(x) = x + x/4 + 768 otherwise
>
> Then
>
> f(1023) = 2046
> f(1024) = 2048
>
> So the function is monotonic (and kind of "smooth")
>
> On Tue, 7 Sep 2021, 02:17 'Keith Randall' via golang-nuts, <
> golang-nuts@googlegroups.com> wrote:
>
>> I don't think this is an important thing to fix, but I agree it is a bit
>> odd. If there's a simple way to restore monotonicity we'll consider it.
>> A similar issue: https://github.com/golang/go/issues/41239
>>
>> On Sunday, September 5, 2021 at 8:59:01 AM UTC-7 jake...@gmail.com wrote:
>>
>>> You are 100% correct. I missed that value. oops
>>>
>>> On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com
>>> wrote:
>>>


 On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
 [...]

> In the example given  (https://play.golang.org/p/RJbEkmFsPKM
> ), the capacities *are 
> *"monotonically
> increasing", as no number in the second column is smaller than the one
> before it.
>

 Nitpick: that is not true.  I copy-pasted the output of the playground
 below.

 0 8
 100 208
 200 416
 300 640
 400 896
 500 1024
 600 1280
 700 1408
 800 1792
 900 2048
 1000 2048
 1100 1408 <-- at this point the new cap is less than for the previous
 row
 1200 1536
 1300 1792
 1400 1792
 1500 2048
 1600 2048
 1700 2304
 1800 2304
 1900 2688

 Regards,

 Arnaud

 On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>
>> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
>> > I'm not sure you're clear about what "monotonically increasing"
>> > means.
>> >
>> > Are you saying that there are some cases where append() results in
>> > the allocated size of a slice *shrinking*? If so, please
>> > demonstrate.
>>
>> I think he means that the cap of the appended slice is not a
>> monotonically increasing function of the cap of the input slice.
>>
>> https://play.golang.org/p/RJbEkmFsPKM
>>
>>
>> --
> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/fa360f3d-e23c-4c07-9505-9f89bd155bb8n%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/CAB%3Df9xRYVD5UW4kqoZQm34rd18BjfYnM0%2BZY9xUpdQeDWKWv7w%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Arnaud Delobelle]

If the growing function is currently

f(x) = 2x for x < 1024
f(x) = x + x/4 otherwise

(Which I haven't checked), couldn't a simple way be to use e.g.

f(x) = 2xfor x < 1024
f(x) = x + x/4 + 768 otherwise

Then

f(1023) = 2046
f(1024) = 2048

So the function is monotonic (and kind of "smooth")

On Tue, 7 Sep 2021, 02:17 'Keith Randall' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

> I don't think this is an important thing to fix, but I agree it is a bit
> odd. If there's a simple way to restore monotonicity we'll consider it.
> A similar issue: https://github.com/golang/go/issues/41239
>
> On Sunday, September 5, 2021 at 8:59:01 AM UTC-7 jake...@gmail.com wrote:
>
>> You are 100% correct. I missed that value. oops
>>
>> On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com wrote:
>>
>>>
>>>
>>> On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
>>> [...]
>>>
 In the example given  (https://play.golang.org/p/RJbEkmFsPKM
 ), the capacities *are 
 *"monotonically
 increasing", as no number in the second column is smaller than the one
 before it.

>>>
>>> Nitpick: that is not true.  I copy-pasted the output of the playground
>>> below.
>>>
>>> 0 8
>>> 100 208
>>> 200 416
>>> 300 640
>>> 400 896
>>> 500 1024
>>> 600 1280
>>> 700 1408
>>> 800 1792
>>> 900 2048
>>> 1000 2048
>>> 1100 1408 <-- at this point the new cap is less than for the previous row
>>> 1200 1536
>>> 1300 1792
>>> 1400 1792
>>> 1500 2048
>>> 1600 2048
>>> 1700 2304
>>> 1800 2304
>>> 1900 2688
>>>
>>> Regards,
>>>
>>> Arnaud
>>>
>>> On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:

> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
> > I'm not sure you're clear about what "monotonically increasing"
> > means.
> >
> > Are you saying that there are some cases where append() results in
> > the allocated size of a slice *shrinking*? If so, please
> > demonstrate.
>
> I think he means that the cap of the appended slice is not a
> monotonically increasing function of the cap of the input slice.
>
> https://play.golang.org/p/RJbEkmFsPKM
>
>
> --
 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/fa360f3d-e23c-4c07-9505-9f89bd155bb8n%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/CAJ6cK1Zk2UcUz37Bcf-z_7wM8%3D3jKJpQvv2d5nE-vsTVVRjLAQ%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Keith Randall' via golang-nuts]

I don't think this is an important thing to fix, but I agree it is a bit 
odd. If there's a simple way to restore monotonicity we'll consider it.
A similar issue: https://github.com/golang/go/issues/41239

On Sunday, September 5, 2021 at 8:59:01 AM UTC-7 jake...@gmail.com wrote:

> You are 100% correct. I missed that value. oops
>
> On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com wrote:
>
>>
>>
>> On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
>> [...]
>>
>>> In the example given  (https://play.golang.org/p/RJbEkmFsPKM 
>>> ), the capacities *are 
>>> *"monotonically 
>>> increasing", as no number in the second column is smaller than the one 
>>> before it.
>>>
>>  
>> Nitpick: that is not true.  I copy-pasted the output of the playground 
>> below.
>>
>> 0 8
>> 100 208
>> 200 416
>> 300 640
>> 400 896
>> 500 1024
>> 600 1280
>> 700 1408
>> 800 1792
>> 900 2048
>> 1000 2048
>> 1100 1408 <-- at this point the new cap is less than for the previous row
>> 1200 1536
>> 1300 1792
>> 1400 1792
>> 1500 2048
>> 1600 2048
>> 1700 2304
>> 1800 2304
>> 1900 2688
>>
>> Regards,
>>
>> Arnaud
>>
>> On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>>>
 On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote: 
 > I'm not sure you're clear about what "monotonically increasing" 
 > means. 
 > 
 > Are you saying that there are some cases where append() results in 
 > the allocated size of a slice *shrinking*? If so, please 
 > demonstrate. 

 I think he means that the cap of the appended slice is not a 
 monotonically increasing function of the cap of the input slice. 

 https://play.golang.org/p/RJbEkmFsPKM 


 -- 
>>> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/fa360f3d-e23c-4c07-9505-9f89bd155bb8n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[jake...@gmail.com]

You are 100% correct. I missed that value. oops

On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com wrote:

>
>
> On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
> [...]
>
>> In the example given  (https://play.golang.org/p/RJbEkmFsPKM 
>> ), the capacities *are 
>> *"monotonically 
>> increasing", as no number in the second column is smaller than the one 
>> before it.
>>
>  
> Nitpick: that is not true.  I copy-pasted the output of the playground 
> below.
>
> 0 8
> 100 208
> 200 416
> 300 640
> 400 896
> 500 1024
> 600 1280
> 700 1408
> 800 1792
> 900 2048
> 1000 2048
> 1100 1408 <-- at this point the new cap is less than for the previous row
> 1200 1536
> 1300 1792
> 1400 1792
> 1500 2048
> 1600 2048
> 1700 2304
> 1800 2304
> 1900 2688
>
> Regards,
>
> Arnaud
>
> On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>>
>>> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote: 
>>> > I'm not sure you're clear about what "monotonically increasing" 
>>> > means. 
>>> > 
>>> > Are you saying that there are some cases where append() results in 
>>> > the allocated size of a slice *shrinking*? If so, please 
>>> > demonstrate. 
>>>
>>> I think he means that the cap of the appended slice is not a 
>>> monotonically increasing function of the cap of the input slice. 
>>>
>>> https://play.golang.org/p/RJbEkmFsPKM 
>>>
>>>
>>> -- 
>> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/4a8d72c1-9f31-48e1-bf08-0022bc11543fn%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Jesper Louis Andersen]

On Sun, Sep 5, 2021 at 3:59 PM jake...@gmail.com  wrote:

> Like Brian, I think part of he problem is possibly a miscommunication
> based on "monotonically increasing". The term means that each point is
> greater than, *or equal to*, the previous one.
> https://en.wikipedia.org/wiki/Monotonic_function. In other words, it
> never decreases. In the example given
> (https://play.golang.org/p/RJbEkmFsPKM
> ), the capacities *are *"monotonically
> increasing", as no number in the second column is smaller than the one
> before it.
>
>
If you take `f` to be a function from the array size to the capacity
increase, it's not, because:

987 < 1024

but we have

f(987) = 2048 and,
f(1024) = 1280

That is f(987) !< f(1024)

breaking monotonicity. It also breaks in the playground at the 1000 and
1100 inputs.

Is it important in most programs? I don't think so. And for those programs
in which it is important, chances are there are other problems you are
facing way before this one rears its head. At least that would be my
expectation.

-- 
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/CAGrdgiU%3Dqxiof3TjXFeAOmGxXuvswv48TOHd%3D_z-qcubu4Cj0A%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Arnaud Delobelle]

On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
[...]

> In the example given  (https://play.golang.org/p/RJbEkmFsPKM
> ), the capacities *are *"monotonically
> increasing", as no number in the second column is smaller than the one
> before it.
>

Nitpick: that is not true.  I copy-pasted the output of the playground
below.

0 8
100 208
200 416
300 640
400 896
500 1024
600 1280
700 1408
800 1792
900 2048
1000 2048
1100 1408 <-- at this point the new cap is less than for the previous row
1200 1536
1300 1792
1400 1792
1500 2048
1600 2048
1700 2304
1800 2304
1900 2688

Regards,

Arnaud

On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>
>> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
>> > I'm not sure you're clear about what "monotonically increasing"
>> > means.
>> >
>> > Are you saying that there are some cases where append() results in
>> > the allocated size of a slice *shrinking*? If so, please
>> > demonstrate.
>>
>> I think he means that the cap of the appended slice is not a
>> monotonically increasing function of the cap of the input slice.
>>
>> https://play.golang.org/p/RJbEkmFsPKM
>>
>>
>> --
> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%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/CAJ6cK1a38cQ%3D55GCW113ygm3bV29FL1VZYD9Jh9mQfQ8C1PUmw%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[jake...@gmail.com]

Like Brian, I think part of he problem is possibly a miscommunication based 
on "monotonically increasing". The term means that each point is greater 
than, *or equal to*, the previous one. 
https://en.wikipedia.org/wiki/Monotonic_function. In other words, it never 
decreases. In the example given  (https://play.golang.org/p/RJbEkmFsPKM 
), the capacities *are *"monotonically 
increasing", as no number in the second column is smaller than the one 
before it. 

On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:

> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
> > I'm not sure you're clear about what "monotonically increasing"
> > means.
> >
> > Are you saying that there are some cases where append() results in
> > the allocated size of a slice *shrinking*? If so, please
> > demonstrate.
>
> I think he means that the cap of the appended slice is not a
> monotonically increasing function of the cap of the input slice.
>
> https://play.golang.org/p/RJbEkmFsPKM
>
>
>

-- 
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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Brian Candler]

Ah I see.  In particular, if you have a slice whose len and cap are both 
1000, the new cap is 2048; but if you have a slice whose len and cap are 
both 1100, then the new cap is 1408.

I don't see that as a problem in any shape or form.  All that's required is:
(1) New cap is at least as large as new required len
(2) Some extra slack on cap to allow for some future growth.  Even that 
requirement is a heuristic, on the grounds that "if you've already appended 
to a slice at least once, then you're likely to append to it again" (but 
you may not).

I agree with what's been said already.  If the OP wants to propose and 
implement a specific new heuristic, and can prove via benchmarking that it 
doesn't degrade performance overall, then let them do so.

-- 
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/35c4ae93-7415-4313-a33e-3b85f99dc42fn%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Dan Kortschak' via golang-nuts]

On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
> I'm not sure you're clear about what "monotonically increasing"
> means.
>
> Are you saying that there are some cases where append() results in
> the allocated size of a slice *shrinking*?  If so, please
> demonstrate.

I think he means that the cap of the appended slice is not a
monotonically increasing function of the cap of the input slice.

https://play.golang.org/p/RJbEkmFsPKM


-- 
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/dedd6e986c8019cc4480fa2b04f327fe632b20e0.camel%40kortschak.io.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Brian Candler]

I'm not sure you're clear about what "monotonically increasing" means.

Are you saying that there are some cases where append() results in the 
allocated size of a slice *shrinking*?  If so, please demonstrate.

-- 
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/409da140-5338-46be-b5c2-7c74a9b7953dn%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 2:26:23 AM UTC-4 axel.wa...@googlemail.com 
wrote:

> On Sun, Sep 5, 2021 at 7:02 AM tapi...@gmail.com  
> wrote:
>
>>
>>
>> On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:
>>
>>> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com  
>>> wrote:
>>>
 Why? That is an undocumented implementation detail. Furthermore, the 
> length of "x1" and "x2" at the time when they are appended to, in 
> combination with the value being appended, are reasonable predictors of 
> the 
> capacity of the new slice. It is up to you to prove that a different 
> heuristic performs better. 
>

 Are there some evidences to prove the current algorithm is better?

>>>
> There are two ways in which the current algorithm may be "better" than the 
> alternative:
> • If the alternative is to always double, then the current algorithm saves 
> significant memory for large slices, which is better.
> • The alternative is to use 1.25 starting at a different threshold (you 
> can't *always* use 1.25, as that would fail for n<4). Finding evidence of 
> whether this is better is easy: change the code, run the benchmarks, see 
> how they change.
>  
>
>> It is your responsibility to show that a different heuristic (not 
>>> "algorithm"). is better. 
>>>
>>
>> I have shown some examples above, which outputs will be more in line with 
>> exception
>> if the heuristic will only depends on the sum length of the two arguments.
>>
>
> Okay. Your expectation is wrong. What's the problem with that?
>
> I have *never* cared about how much `append` grows a slice. Not even 
> once. Even if I had cared to make a prediction and that prediction turned 
> out wrong, it would never have mattered. Why do you think it does?
>

No expectations are wrong, or right. They are like personal tastes.
Personally, I think monotonically increasing is good taste.
 

>  
>
>>
>> Clarification: I don't think the exponential growth algorithm is bad.
>> I just think it should make the capacities increase monotonically.
>>  
>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>>
> 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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%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/88b20816-3c6b-4830-af53-ed3b988d81e0n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Axel Wagner' via golang-nuts]

On Sun, Sep 5, 2021 at 7:02 AM tapi...@gmail.com 
wrote:

>
>
> On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:
>
>> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com 
>> wrote:
>>
>>> Why? That is an undocumented implementation detail. Furthermore, the
 length of "x1" and "x2" at the time when they are appended to, in
 combination with the value being appended, are reasonable predictors of the
 capacity of the new slice. It is up to you to prove that a different
 heuristic performs better.

>>>
>>> Are there some evidences to prove the current algorithm is better?
>>>
>>
There are two ways in which the current algorithm may be "better" than the
alternative:
• If the alternative is to always double, then the current algorithm saves
significant memory for large slices, which is better.
• The alternative is to use 1.25 starting at a different threshold (you
can't *always* use 1.25, as that would fail for n<4). Finding evidence of
whether this is better is easy: change the code, run the benchmarks, see
how they change.


> It is your responsibility to show that a different heuristic (not
>> "algorithm"). is better.
>>
>
> I have shown some examples above, which outputs will be more in line with
> exception
> if the heuristic will only depends on the sum length of the two arguments.
>

Okay. Your expectation is wrong. What's the problem with that?

I have *never* cared about how much `append` grows a slice. Not even once.
Even if I had cared to make a prediction and that prediction turned out
wrong, it would never have mattered. Why do you think it does?


>
> Clarification: I don't think the exponential growth algorithm is bad.
> I just think it should make the capacities increase monotonically.
>
>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> 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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%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/CAEkBMfHFxDUtxUHseMp0_ahizFsm3Z%3DzJTsMFMT3%2BbEcXKY5ug%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com  
> wrote:
>
>> Why? That is an undocumented implementation detail. Furthermore, the 
>>> length of "x1" and "x2" at the time when they are appended to, in 
>>> combination with the value being appended, are reasonable predictors of the 
>>> capacity of the new slice. It is up to you to prove that a different 
>>> heuristic performs better. 
>>>
>>
>> Are there some evidences to prove the current algorithm is better?
>>
>
> It is your responsibility to show that a different heuristic (not 
> "algorithm"). is better. 
>

I have shown some examples above, which outputs will be more in line with 
exception
if the heuristic will only depends on the sum length of the two arguments.

Clarification: I don't think the exponential growth algorithm is bad.
I just think it should make the capacities increase monotonically.
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com 
wrote:

> Why? That is an undocumented implementation detail. Furthermore, the
>> length of "x1" and "x2" at the time when they are appended to, in
>> combination with the value being appended, are reasonable predictors of the
>> capacity of the new slice. It is up to you to prove that a different
>> heuristic performs better.
>>
>
> Are there some evidences to prove the current algorithm is better?
>

It is your responsibility to show that a different heuristic (not
"algorithm"). is better.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9gN5Qw%3D3txpcoBtsm565REmyOOSzLX3kiB-CAbpdoBgA%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:12:46 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 8:57 PM 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  
>>> 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.
>>
>
> Okay, I agree that technically your use of "monotonically increasing" does 
> not preclude exponential growth. However, your contrasting the behavior 
> around the pivot point of 1024 implies that exponential growth is excluded 
> since the growth is exponential on each side of the pivot point and you 
> stated it was "monotonically increasing" on one side but not the other. 
>

My opinions include:
1. there should not be a slip in the whole number range.
2. the increasing should totally depend on the sum length of the two 
arguments.
 

>  
>
>> 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.
>>
>
> Why? That is an undocumented implementation detail. Furthermore, the 
> length of "x1" and "x2" at the time when they are appended to, in 
> combination with the value being appended, are reasonable predictors of the 
> capacity of the new slice. It is up to you to prove that a different 
> heuristic performs better. 
>

Are there some evidences to prove the current algorithm is better?
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/1b4a000d-a71b-4d89-b509-9201b81ba547n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:16:48 AM UTC-4 kortschak wrote:

> 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. 
>

Yes, this is the current algorithm. I don't think aligning to a nearby 
memory block size is a problem.
Personally, I think the slice grow algorithm should not depend on slice 
capacities.
 

>
> 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  > > > 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/ca26dfa4-03d0-425f-a6b4-2b80e5f7e65an%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Dan Kortschak' via golang-nuts]

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  > > 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.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 8:57 PM 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 
>> 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.
>

Okay, I agree that technically your use of "monotonically increasing" does
not preclude exponential growth. However, your contrasting the behavior
around the pivot point of 1024 implies that exponential growth is excluded
since the growth is exponential on each side of the pivot point and you
stated it was "monotonically increasing" on one side but not the other.


> 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.
>

Why? That is an undocumented implementation detail. Furthermore, the length
of "x1" and "x2" at the time when they are appended to, in combination with
the value being appended, are reasonable predictors of the capacity of the
new slice. It is up to you to prove that a different heuristic performs
better.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-_ytZbLZzSMHTro7ej%2BE4UKk7e%2BCep4Z24W5Myf47iZA%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

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  
> 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
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/529b4ee9-14a8-4145-853d-1ebdb9e9fa67n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 8:39 PM 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.


> 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.


> 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
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9yaLXYL66HGYgYupnk4a%2BUQGpT-9srGUKoGxhHT%2Bk7kQ%40mail.gmail.com.