Today I was exploring some unexpected allocations that came from creating
empty interface{} values wrapping a string and an int. I spent some time
trying to clarify my understanding so I wouldn't be surprised in the future.
I have consulted this excellent page
http://research.swtch.com/interfaces and written a small set of benchmarks.
I am running Go 1.7
My understanding of an interface is that it is made up of a pair of
pointers. The first is a pointer to an itable containing the concrete type
and a table of functions. The second pointer is to the data itself. We can
write this [*itable, *data].
If we want to create an interface{} wrapping a string then we need to be
able to point to its itable and to the string itself. We assume the itable
already exists and we can point to it efficiently. However, although a
string behaves like a pointer it is a complex value containing [*data,
length] (I'll call this data structure a string-descriptor), so we can't
just use that as a pointer in our interface. We need to allocate the
string-descriptor, and the interface can then point to that location on the
heap.
This is broadly true of most values in Go, as many pointer-like things are
actually complex values. But we would expect that an interface wrapping an
actual pointer wouldn't need to allocate at all.
The benchmarks in the gist below seem to confirm that. However, there were
a mistakes and false paths in putting these benchmarks together so I would
appreciate it if someone could confirm that what I have described above is
true. And if it is not true, could you please clarify.
https://gist.github.com/fmstephe/f0e2fbd6a43b70a86ec08125684adfe3
Thanks
--
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.
For more options, visit https://groups.google.com/d/optout.
