s/hard/harm On Wednesday, October 2, 2024 at 12:50:59 PM UTC+8 tapi...@gmail.com wrote:
> On Monday, September 30, 2024 at 1:51:17 PM UTC+8 Hikmatulloh Hari Mukti > (Hari) wrote: > > > Maybe I should apologize for the origin of this idea: > https://github.com/go101/go101/wiki/How-to-perfectly-clone-a-slice%3F > > No worries, I learn a lot from articles you posted on go101.org, > appreciate it. > > > My current opinion is that it is best to let the Go runtime specialize > zero-capacity slicing: > https://github.com/golang/go/issues/68488#issuecomment-2267179883 > > This means both of these will point to *runtime.zerobase*, is that > correct? > s := make([]int, 0) > > > I'm not aware of any hard by letting the underlying array of s point to > *runtime.zerobase.* > > > s := x[:0:0] > > If that's the case, if someone intentionally keeps alive slice's > underlying array using s[:0:0], wouldn't the behavior of that program be > affected? I don't know if there is real world case for this though. > > > If someone want to intentionally keep alive slice's underlying array, > she/he can use s[:0] instead. > > > On Friday 27 September 2024 at 14:16:36 UTC+7 tapi...@gmail.com wrote: > > Maybe I should apologize for the origin of this idea: > https://github.com/go101/go101/wiki/How-to-perfectly-clone-a-slice%3F > > When I posted that wiki article, I was not aware of this (maybe tiny) > drawback. > > My current opinion is that it is best to let the Go runtime specialize > zero-capacity slicing: > https://github.com/golang/go/issues/68488#issuecomment-2267179883 > > On Thursday, September 26, 2024 at 8:29:59 PM UTC+8 Hikmatulloh Hari Mukti > (Hari) wrote: > > Hi gophers, I want to know the reason behind the decision of using > *append(s[:0:0], > s...)* over the previous code since the two code return different slice > when dealing slice with zero len. The previous code will return brand new > slice with size zero, while the current code return an empty slice that's > still pointing to the previous array. And also, why not maybe using > *append(S(nil), > s...)* instead? This will return nil when dealing with zero len slice > though, but what's the potential problem that it will cause? > > I don't know if this can be considered for a problem, but here is my > concern for the current code, *append(s[:0:0], s...)* : > > If we try to create slices from an array pool to reduce allocation by > using append, and many our slices turned out to be zero, slices.Clone will > return slice that still pointing to array in the pool. If we try creating > many of them concurrently, (if I understand it correctly) the pool may try > to create many array objects as the object retrieved from Get may haven't > been Put back to the pool. Those array objects can only be > garbage-collected after those slices are no longer used / reachable and if > it's an array of a big struct, wouldn't it might potentially pressure the > memory? > > Here is just a pseudo-code for illustration only. I think the array > generated by pool will only be garbage-collected once *ch* is consumed > and the slices are no longer used: > > var pool = sync.Pool{New: func() any { return &[255]bigstruct{} }} > var ch = make(chan []bigstruct, 1000) > for i := 0; i < 1000; i++ { > go func() { > arr := pool.Get().(*[255]bigstruct) > defer pool.Put(arr) > s := arr[:0] > ch <- slices.Clone(s) // slice points to arr > }() > } > > > CMIIW and thank you! > > > > -- 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/66fbe030-a973-442c-95c0-819551c09d60n%40googlegroups.com.
