В целом, когда речь идет об эффективности, вы должны запускать тесты.
Давайте создадим очень простые примеры:
func fuint() uint {
return 0
}
func fpuint() *uint {
var i uint
return &i
}
И код тестирования:
func BenchmarkUint(b *testing.B) {
for i := 0; i < b.N; i++ {
fuint()
}
}
func BenchmarkPuint(b *testing.B) {
for i := 0; i < b.N; i++ {
fpuint()
}
}
Стоит обратить внимание на одну вещь: поскольку у нас очень простые функции, оптимизация кода может сделать результат бесполезным (например, мы можем увидеть тот же результат).
Поэтому вместо этого мы должны протестировать, отключив оптимизацию компилятора.Итак, давайте проверим это так:
go test -gcflags '-N -l' -bench . -benchmem
Результаты теста:
BenchmarkUint-4 500000000 3.21 ns/op 0 B/op 0 allocs/op
BenchmarkPuint-4 100000000 22.4 ns/op 8 B/op 1 allocs/op
Как мы и могли догадаться: выделение значения uint и возврат указателя на него происходит медленнееи требует выделения (в куче), тогда как возвращение простого uint значения не дает.
Но не думайте, что это всегда так.Во время этого теста мы отключили оптимизацию компилятора.Когда вы компилируете свое приложение в производство, вы, очевидно, не отключите оптимизацию, поэтому ваши реальные примеры могут не иметь такой большой разницы или вообще никакой разницы.Протестируйте / сравните ваш реальный код, чтобы увидеть, действительно ли возвращение указателя имеет какую-либо заметную разницу.
Для справки, вот результат с включенной оптимизацией компилятора (поведение по умолчанию):
go test -bench . -benchmem
BenchmarkUint-4 2000000000 0.35 ns/op 0 B/op 0 allocs/op
BenchmarkPuint-4 2000000000 0.35 ns/op 0 B/op 0 allocs/op
Мыне вижу разницы для fuint() и fpuint() вообще в конкретных примерах выше .