Understanding Pointer Operations & CPU/Memory usage

I was talking to a colleague at work about whether or not it's more efficient to pass a pointer to a function and/or returning a pointer.

I put together some bench mark functions to test the different ways of doing this. The functions basically accept a variable, transform it and pass it back. We have 4 different ways of doing it:

1. Pass the variable in normally, create a new variable for the result of the transformation and pass back a copy of it
2. Pass the variable in normally, create a new variable for the result of the transformation, and pass back the memory address
3. Pass in a pointer to a variable, create a new variable for the result of the transformation and pass back a copy of that variable
4. Pass in a pointer to a variable, perform the transformation on the value of the pointer, nothing to pass back.

package main

import (
	"fmt"
	"testing"
)

type MyStruct struct {
	myString string
}

func acceptParamReturnVariable(s MyStruct) MyStruct {
	ns := MyStruct{
		fmt.Sprintf("I'm quoting this: \"%s\"", s.myString),
	}
	return ns
}

func acceptParamReturnPointer(s MyStruct) *MyStruct {
	ns := MyStruct{
		fmt.Sprintf("I'm quoting this: \"%s\"", s.myString),
	}
	return &ns
}

func acceptPointerParamReturnVariable(s *MyStruct) MyStruct {
	ns := MyStruct{
		fmt.Sprintf("I'm quoting this: \"%s\"", s.myString),
	}
	return ns
}

func acceptPointerParamNoReturn(s *MyStruct) {
	s.myString = fmt.Sprintf("I'm quoting this: \"%s\"", s.myString)
}

func BenchmarkNormalParamReturnVariable(b *testing.B) {
	s := MyStruct{
		myString: "Hello World",
	}
	var ns MyStruct
	for i := 0; i < b.N; i++ {
		ns = acceptParamReturnVariable(s)
	}
	_ = ns
}

func BenchmarkNormalParamReturnPointer(b *testing.B) {
	s := MyStruct{
		myString: "Hello World",
	}
	var ns *MyStruct
	for i := 0; i < b.N; i++ {
		ns = acceptParamReturnPointer(s)
	}
	_ = ns
}

func BenchmarkPointerParamReturnVariable(b *testing.B) {
	s := MyStruct{
		myString: "Hello World",
	}
	var ns MyStruct
	for i := 0; i < b.N; i++ {
		ns = acceptPointerParamReturnVariable(&s)
	}
	_ = ns
}

func BenchmarkPointerParamNoReturn(b *testing.B) {
	s := MyStruct{
		myString: "Hello World",
	}
	for i := 0; i < b.N; i++ {
		acceptPointerParamNoReturn(&s)
	}
	_ = s
}

I found the results rather surprising.

$ go test -run=XXXX -bench=. -benchmem
goos: darwin
goarch: amd64
pkg: XXXX
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
BenchmarkNormalParamReturnVariable-16           10538138               103.3 ns/op            48 B/op          2 allocs/op
BenchmarkNormalParamReturnPointer-16             9526380               201.2 ns/op            64 B/op          3 allocs/op
BenchmarkPointerParamReturnVariable-16           7542066               147.0 ns/op            48 B/op          2 allocs/op
BenchmarkPointerParamNoReturn-16                   45897            119265 ns/op          924351 B/op          5 allocs/op

Before running this, I figured the most efficient way would have been the 4th test, since no new variables are being created in the scope of the function being called and only memory addressed are being passed around, however, it seems that the 4th one is the least efficient, taking the most time, as well as using the most memory too.

Could some one possible explain this to me, or provide me with some good reading links that explain this?

Benchmarks you do don't answer the questions you ask. Microbenchmarking is proven to be extremely hard - not only in Go world but in general.

Coming back to the efficiency problem. Typically, passing a pointer to a function doesn't escape to the heap. And typically, returning a pointer from a function does escape to the heap. Typically is the key word here. You can't really say when the compiler allocates something on the stack and when on the heap. This is not a trivial problem. Really good and short explanation can be found here.

But if you need to know, you can ask. You can start by simply printing optimization decisions made by the compiler. You can do so by passing the m flag to the go tool compile.

go build -gcflags -m=1 

If you pass integer greater than 1 you get more verbose output. If it doesn't give you the answer you need to optimize your program, then try profiling. It goes much beyond the memory analysis.

In general, in your daily work do not bother with naive optimization decisions. Don't get too attached to the statements saying 'Typically...' because in real world, you never know. Always aim at the correctness optimization first. And then do the performance optimization only if you really need it and you proved that you need it. Do not guess, do not trust. Also, keep in mind, Go is changing so what we prove in one version, doesn't have to be true in the other.