Thanks. So basically, there's no memory benefit or performance benefit to
using nil slices over empty slices -- it's ultimately just a matter of how
you want them to serialize JSON or get written to databases?
mathew
On Wednesday, September 7, 2022 at 6:56:33 PM UTC-5 k...@google.com wrote:
> (Actually, that address is an address on the stack, but that's only
> because the backing store for emptySlice does not escape. It should also
> take ~no space.)
>
> On Wednesday, September 7, 2022 at 4:53:12 PM UTC-7 Keith Randall wrote:
>
>> That address is not in the heap. It is the address of a special word in
>> the runtime, called runtime.zerobase, which is explicitly for this purpose.
>> It is a place to point things that need to be non-nil but have no size.
>>
>> On Wednesday, September 7, 2022 at 12:01:28 PM UTC-7 me...@pobox.com
>> wrote:
>>
>>> Running this:
>>>
>>> emptyslice := []string{}
>>> sh := (*reflect.SliceHeader)(unsafe.Pointer(&emptyslice))
>>> fmt.Printf("empty slice cap = %d\n", sh.Cap)
>>> fmt.Printf("empty slice len = %d\n", sh.Len)
>>> fmt.Printf("empty slice uintptr = %v\n", sh.Data)
>>>
>>> Output:
>>>
>>> empty slice cap = 0
>>> empty slice len = 0
>>> empty slice uintptr = 824634224152
>>>
>>> The non-zero uintptr suggests that something is allocated on the heap.
>>> But the cap is 0, so any backing array should have a size of 0. So what is
>>> allocated on the heap? Surely not an array of size 0?
>>>
>>>
>>> mathew
>>>
>>
--
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/ab489f02-e391-41cd-93ef-e415661a886bn%40googlegroups.com.
