The normal rule of thumb is that if you have small structs, you should pass them by value, rather than by pointer.
So in gSuneido (the Go implementation of Suneido I'm working on) that's what I'm doing.
But I was thinking about the way interfaces work in Go. An interface can only hold a pointer. So if you do:
var i interface{} = x
and x is not a pointer, then x will be copied to the heap so that i can point to it.
Some simple cases avoid the allocation. For example, true, false, and empty string ("") can be assigned to an interface without causing allocation. Presumably because the runtime has a shared value it can point to.
Suneido is dynamically typed, so values are stored and passed around as Value interfaces. (The equivalent of an abstract base class in C++ or Java.)
Given this, does it still make sense to "pass" small structs by value? Or is that just going to cause heap allocation?
I made a quick benchmark.
And the results were:
As expected, when we pass by value, we get a heap allocation every time, making it about 10 times slower. That's a bit misleading because the benchmark doesn't do any real work. e.g. if it was doing 500ns of work, then the comparison would be 520ns versus 502ns which is much less significant.
However, the allocation is more of a concern. Heap allocation has bigger, more widespread affects like garbage collection and cache pressure and memory bandwidth. These aren't always evident from a benchmark.
With these kinds of micro-benchmarks I'm always afraid the compiler has optimized away key parts of the code. But I used Compiler Explorer to look at the code generated, and it all seems to be there.
Somewhat surprisingly, I got the same results for a simple string rather than a struct - it's faster to pass a pointer to a string. Coming from C++ or Java, you think of a string as already being a pointer. But in Go it's more like a slice, i.e. it's actually a small struct containing a pointer and a length. Because it's a small struct, you normally pass it by value. But when you use interfaces, that means heap allocation (of the slice struct as well as the actual bytes of the content).
Unless I'm missing something, it seems like I should change gSuneido to use pointers for all values, even strings.
So in gSuneido (the Go implementation of Suneido I'm working on) that's what I'm doing.
But I was thinking about the way interfaces work in Go. An interface can only hold a pointer. So if you do:
var i interface{} = x
and x is not a pointer, then x will be copied to the heap so that i can point to it.
Some simple cases avoid the allocation. For example, true, false, and empty string ("") can be assigned to an interface without causing allocation. Presumably because the runtime has a shared value it can point to.
Suneido is dynamically typed, so values are stored and passed around as Value interfaces. (The equivalent of an abstract base class in C++ or Java.)
Given this, does it still make sense to "pass" small structs by value? Or is that just going to cause heap allocation?
I made a quick benchmark.
And the results were:
BenchmarkSmallByValue 20.7 ns/op 16 B/op 1 allocs/op BenchmarkSmallByPointer 2.09 ns/op 0 B/op 0 allocs/op
As expected, when we pass by value, we get a heap allocation every time, making it about 10 times slower. That's a bit misleading because the benchmark doesn't do any real work. e.g. if it was doing 500ns of work, then the comparison would be 520ns versus 502ns which is much less significant.
However, the allocation is more of a concern. Heap allocation has bigger, more widespread affects like garbage collection and cache pressure and memory bandwidth. These aren't always evident from a benchmark.
With these kinds of micro-benchmarks I'm always afraid the compiler has optimized away key parts of the code. But I used Compiler Explorer to look at the code generated, and it all seems to be there.
Somewhat surprisingly, I got the same results for a simple string rather than a struct - it's faster to pass a pointer to a string. Coming from C++ or Java, you think of a string as already being a pointer. But in Go it's more like a slice, i.e. it's actually a small struct containing a pointer and a length. Because it's a small struct, you normally pass it by value. But when you use interfaces, that means heap allocation (of the slice struct as well as the actual bytes of the content).
Unless I'm missing something, it seems like I should change gSuneido to use pointers for all values, even strings.
