Hello,
I read this article and it left me confused. Unlocking Go Slice
Performance: Navigating sync.Pool for Enhanced Efficiency | by Mike Norgate
| Medium
<https://blog.mike.norgate.xyz/unlocking-go-slice-performance-navigating-sync-pool-for-enhanced-efficiency-7cb63b0b453e>.
(sorry for paywall).
I roughly understand what this is getting at but in so confused about the
capacity. In the final code block, they are showing this
```go
func BenchmarkSlicePtrPool_3(b *testing.B) {
pool := sync.Pool{
New: func() interface{} {
s := make([]int, 0, 0)
return &s
},
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
ptr := pool.Get().(*[]int)
s := *ptr
s = s[0:0]
s = append(s, 123)
*ptr = s // Copy the stack header over to the heap
pool.Put(ptr)
}
}
```
As I understand, this fixes the "old" header still pointing at the "old"
capacity. But where does the capcity come from?
If growslice results in alloc, then this code should have 1 allocation. Is
this hidden in their benchmark output, because it only happend on iteration
1?
Putting the confusion aside, is this even good? Returning a pointer to
slice with 0 capacity from the pool and let the caller grow it?
Kind regards,
Nico
--
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/a5ead66c-58d5-436e-a095-bb20d931af97n%40googlegroups.com.
