Go: передача значений VS передача указателей
Go — один из немногих языков, в которых структуры можно передавать параметрами и возвращать из функций как по значению, так и по указателю. Это приводит к большей выразительности языка, но также разделяет общество разработчиков Go на два лагеря: сторонников указателей и сторонников значений.
В данной статье предлагается во многом субъективное сравнение обоих способов и делается попытка убедить читателей передавать и возвращать значения в тех случаях, где это возможно.
Читаемость
Параметр
Самое простое и, наверное, самое главное свойство кода — это его читаемость. Указатели имеют больше возможных значений, так что работать с ними оказывается немного сложнее, чем со значениями. Например:
func foo(ctx context.Context, user *User, order *Order) (*Receipt, error) {
// ...
}
При рефакторинге такой функции будет проскальзывать мысль:, а не может ли одним из параметров функции быть передан nil? Даже если это маловероятно и разработчики договорились/из документации следует, что nil передан не будет, есть ли гарантии, что nil не попадет сюда по ошибке? Кто-то из разработчиков может добавить новую функциональность, вызывающую данную функцию, и забыть добавить проверку на nil. А может из функции, которая никогда ранее не возвращала nil, начать его возвращать.
Разумеется, никто не мешает вызывать функцию
func foo(ctx context.Context, user User, order Order) (Receipt, error) {
// ...
}
как foo(context.TODO(), User{}, Order{}), однако это хотя бы сообщает, что в функцию должны быть переданы non-nil значения, а валидация отдельных полей — уже ответственность самой функции. Однако уже можно быть уверенным, что при доступе к user и order паник не будет, и явные проверки типа if order == nil { return } уже не нужны.
Возвращаемое значение
При возврате функцией значения вместо указателя, написание return Receipt{}, err занимает лишь немногим больше времени, чем return nil, err, однако у вызывающей стороны не будет необходимости проверять значение на nil (кто из нас не делал return nil, nil хотя бы раз в жизни?), не будет необходимости разыменовывать указатель при передаче куда-либо. Преимущества тут уже не настолько видны, т. к. принято возвращать либо значение и ошибку nil, либо значение nil/пустое значение и ошибку.
Производительность
Бывают ситуации, когда функции принимают и возвращают указатели на большие по мнению разработчиков структуры, поэтому и передача их осуществляется по указателю с целью сэкономить время на копировании структуры. При этом, как правило, никто не пишет бенчмарки и не смотрит аннотации компилятора, потому что ситуация кажется очевидной — зачем передавать структуру размером в 1 КБ, когда можно передать указатель в 128 раз меньше?
Однако на практике данное решение может привести к менее производительному коду. Например, если взять маппинг двух структур:
type User struct {
ID int64
CreatedAt, UpdatedAt, DeletedAt time.Time
FirstName, SecondName, Patronymic string
Birthday time.Time
Nationality string
UserType int
Balance *big.Rat
BonusPoints *big.Rat
}
type UserDTO struct {
ID int64
CreatedAt, UpdatedAt, DeletedAt time.Time
FirstName, SecondName, Patronymic string
Birthday time.Time
Nationality string
UserType int
Balance *big.Rat
BonusPoints *big.Rat
FullName string
BalanceWithBonusPoints *big.Rat
}
func UserToDTO(u User) UserDTO {
return UserDTO{
ID: u.ID,
CreatedAt: u.CreatedAt,
UpdatedAt: u.UpdatedAt,
DeletedAt: u.DeletedAt,
FirstName: u.FirstName,
SecondName: u.SecondName,
Patronymic: u.Patronymic,
Birthday: u.Birthday,
Nationality: u.Nationality,
UserType: u.UserType,
Balance: u.Balance,
BonusPoints: u.BonusPoints,
FullName: u.FirstName + " " + u.SecondName + " " + u.Patronymic,
BalanceWithBonusPoints: new(big.Rat).Add(u.Balance, u.BonusPoints),
}
}
func DTOToUser(d UserDTO) User {
return User{
ID: d.ID,
CreatedAt: d.CreatedAt,
UpdatedAt: d.UpdatedAt,
DeletedAt: d.DeletedAt,
FirstName: d.FirstName,
SecondName: d.SecondName,
Patronymic: d.Patronymic,
Birthday: d.Birthday,
Nationality: d.Nationality,
UserType: d.UserType,
Balance: d.Balance,
BonusPoints: d.BonusPoints,
}
}
func UserPtrToDTO(u *User) *UserDTO {
return &UserDTO{
ID: u.ID,
CreatedAt: u.CreatedAt,
UpdatedAt: u.UpdatedAt,
DeletedAt: u.DeletedAt,
FirstName: u.FirstName,
SecondName: u.SecondName,
Patronymic: u.Patronymic,
Birthday: u.Birthday,
Nationality: u.Nationality,
UserType: u.UserType,
Balance: u.Balance,
BonusPoints: u.BonusPoints,
FullName: u.FirstName + " " + u.SecondName + " " + u.Patronymic,
BalanceWithBonusPoints: new(big.Rat).Add(u.Balance, u.BonusPoints),
}
}
func DTOPtrToUser(d *UserDTO) *User {
return &User{
ID: d.ID,
CreatedAt: d.CreatedAt,
UpdatedAt: d.UpdatedAt,
DeletedAt: d.DeletedAt,
FirstName: d.FirstName,
SecondName: d.SecondName,
Patronymic: d.Patronymic,
Birthday: d.Birthday,
Nationality: d.Nationality,
UserType: d.UserType,
Balance: d.Balance,
BonusPoints: d.BonusPoints,
}
}
и такой бенчмарк:
func BenchmarkMapValues(b *testing.B) {
var (
user = createUser()
res pointers.User
)
b.ResetTimer()
for i := 0; i < b.N; i++ {
dto := pointers.UserToDTO(user)
res = pointers.DTOToUser(dto)
}
_ = res
}
func BenchmarkMapPointers(b *testing.B) {
var (
user = createUser()
res *pointers.User
)
b.ResetTimer()
for i := 0; i < b.N; i++ {
dto := pointers.UserPtrToDTO(&user)
res = pointers.DTOPtrToUser(dto)
}
_ = res
}
func createUser() pointers.User {
return pointers.User{
ID: 1,
CreatedAt: time.Now(),
UpdatedAt: time.Now(),
DeletedAt: time.Now(),
FirstName: "John",
SecondName: "Doe",
Patronymic: "Smith",
Birthday: time.Date(1970, 1, 1, 0, 0, 0, 0, time.UTC),
Nationality: "Russian",
UserType: 1,
Balance: big.NewRat(1000, 1),
BonusPoints: big.NewRat(100, 1),
}
}
и запустить его вот так:
go test -benchmem -bench . ./...
то можно получить вот такой результат:
goos: windows
goarch: amd64
pkg: articles/src/pointers
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkMapValues-16 4174956 289.7 ns/op 288 B/op 8 allocs/op
BenchmarkMapPointers-16 3207511 385.7 ns/op 704 B/op 10 allocs/op
Структура, разумеется, небольшая, но что более важно — при каждом вызове функции, возвращающей указатель, происходит дополнительное выделение памяти в куче, чего нет в функции, возвращающей значение.
Уберем из функций операции, приводящие к дополнительному выделению памяти в куче:
Код
type User_NoHeap struct {
ID int64
CreatedAt, UpdatedAt, DeletedAt time.Time
FirstName, SecondName, Patronymic string
Birthday time.Time
Nationality string
UserType int
Balance *big.Rat
BonusPoints *big.Rat
}
type UserDTO_NoHeap struct {
ID int64
CreatedAt, UpdatedAt, DeletedAt time.Time
FirstName, SecondName, Patronymic string
Birthday time.Time
Nationality string
UserType int
Balance *big.Rat
BonusPoints *big.Rat
}
func UserToDTO_NoHeap(u User_NoHeap) UserDTO_NoHeap {
return UserDTO_NoHeap{
ID: u.ID,
CreatedAt: u.CreatedAt,
UpdatedAt: u.UpdatedAt,
DeletedAt: u.DeletedAt,
FirstName: u.FirstName,
SecondName: u.SecondName,
Patronymic: u.Patronymic,
Birthday: u.Birthday,
Nationality: u.Nationality,
UserType: u.UserType,
Balance: u.Balance,
BonusPoints: u.BonusPoints,
}
}
func DTOToUser_NoHeap(d UserDTO_NoHeap) User_NoHeap {
return User_NoHeap{
ID: d.ID,
CreatedAt: d.CreatedAt,
UpdatedAt: d.UpdatedAt,
DeletedAt: d.DeletedAt,
FirstName: d.FirstName,
SecondName: d.SecondName,
Patronymic: d.Patronymic,
Birthday: d.Birthday,
Nationality: d.Nationality,
UserType: d.UserType,
Balance: d.Balance,
BonusPoints: d.BonusPoints,
}
}
func UserPtrToDTO_NoHeap(u *User_NoHeap) *UserDTO_NoHeap {
return &UserDTO_NoHeap{
ID: u.ID,
CreatedAt: u.CreatedAt,
UpdatedAt: u.UpdatedAt,
DeletedAt: u.DeletedAt,
FirstName: u.FirstName,
SecondName: u.SecondName,
Patronymic: u.Patronymic,
Birthday: u.Birthday,
Nationality: u.Nationality,
UserType: u.UserType,
Balance: u.Balance,
BonusPoints: u.BonusPoints,
}
}
func DTOPtrToUser_NoHeap(d *UserDTO_NoHeap) *User_NoHeap {
return &User_NoHeap{
ID: d.ID,
CreatedAt: d.CreatedAt,
UpdatedAt: d.UpdatedAt,
DeletedAt: d.DeletedAt,
FirstName: d.FirstName,
SecondName: d.SecondName,
Patronymic: d.Patronymic,
Birthday: d.Birthday,
Nationality: d.Nationality,
UserType: d.UserType,
Balance: d.Balance,
BonusPoints: d.BonusPoints,
}
}
Также возьмем структуры размером 2 КБ, 8 КБ и 1 МБ (функции также без дополнительного выделения памяти в куче):
type User2KB struct {
Data [2048]byte
}
type UserDTO2KB struct {
Data [2048]byte
}
func UserToDTO2KB(u User2KB) UserDTO2KB {
return UserDTO2KB{
Data: u.Data,
}
}
func DTOToUser2KB(d UserDTO2KB) User2KB {
return User2KB{
Data: d.Data,
}
}
func UserPtrToDTO2KB(u *User2KB) *UserDTO2KB {
return &UserDTO2KB{
Data: u.Data,
}
}
func DTOPtrToUser2KB(d *UserDTO2KB) *User2KB {
return &User2KB{
Data: d.Data,
}
}
Результат при этом получается вот таким:
goos: windows
goarch: amd64
pkg: articles/src/pointers
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkMapValues1MB-16 9324 123896 ns/op 0 B/op 0 allocs/op
BenchmarkMapPointers1MB-16 5163 218242 ns/op 2097156 B/op 2 allocs/op
BenchmarkMapValues2KB-16 6429981 186.2 ns/op 0 B/op 0 allocs/op
BenchmarkMapPointers2KB-16 2866360 416.5 ns/op 2048 B/op 1 allocs/op
BenchmarkMapValues8KB-16 2202045 544.4 ns/op 0 B/op 0 allocs/op
BenchmarkMapPointers8KB-16 773160 1548 ns/op 8192 B/op 1 allocs/op
BenchmarkMapValuesNoHeap-16 41105602 28.50 ns/op 0 B/op 0 allocs/op
BenchmarkMapPointersNoHeap-16 18602142 58.65 ns/op 192 B/op 1 allocs/op
BenchmarkMapValues-16 3729990 330.7 ns/op 288 B/op 8 allocs/op
BenchmarkMapPointers-16 2999234 396.9 ns/op 704 B/op 10 allocs/op
Также я взял большую структуру из кода на работе (которую не покажу), которая по размеру немного меньше 1 КБ. Результаты замены единственной строки (func convert(x *X) *Y → func convert(x X) Y) таковы (третий бенчмарк — это передача *&X{}, а в остальном он аналогичен первому):
goos: windows
goarch: amd64
pkg: supercompany/code
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkValue-16 2789080 411.7 ns/op 432 B/op 7 allocs/op
BenchmarkPointer-16 1767438 673.8 ns/op 1136 B/op 8 allocs/op
BenchmarkDereferencePointerToValue-16 2450964 422.3 ns/op 432 B/op 7 allocs/op
Fizzbuzz
Как можно написать серьезную статью без как минимум одного сложного и научного алгоритма? Реализуем fizzbuzz!
Сделаем две реализации: одна будет по возможности использовать передачу структур по значению (копирование), а вторая — передачу по указателю, а затем сравним их производительность.
Реализация
type ControllerReq struct {
From, To int
}
type ControllerResp struct {
Values map[int]string
}
type logicReq struct {
value int
}
type logicResp struct {
value string
}
func ValueController(ctx context.Context, req *ControllerReq) (*ControllerResp, error) {
res := make(map[int]string, req.To-req.From)
for i := req.From; i < req.To; i++ {
x, err := valueLogic(ctx, logicReq{i})
if err != nil {
return nil, err
}
res[i] = x.value
}
return &ControllerResp{res}, nil
}
func valueLogic(ctx context.Context, req logicReq) (logicResp, error) {
var (
divisibleBy3 = req.value%3 == 0
divisibleBy5 = req.value%5 == 0
)
switch {
case divisibleBy3 && divisibleBy5:
return logicResp{"fizzbuzz"}, nil
case divisibleBy3:
return logicResp{"fizz"}, nil
case divisibleBy5:
return logicResp{"buzz"}, nil
default:
return logicResp{strconv.FormatInt(int64(req.value), 10)}, nil
}
}
func PtrController(ctx context.Context, req *ControllerReq) (*ControllerResp, error) {
res := make(map[int]string, req.To-req.From)
for i := req.From; i < req.To; i++ {
x, err := ptrLogic(ctx, &logicReq{i})
if err != nil {
return nil, err
}
res[i] = x.value
}
return &ControllerResp{res}, nil
}
func ptrLogic(ctx context.Context, req *logicReq) (*logicResp, error) {
var (
divisibleBy3 = req.value%3 == 0
divisibleBy5 = req.value%5 == 0
)
switch {
case divisibleBy3 && divisibleBy5:
return &logicResp{"fizzbuzz"}, nil
case divisibleBy3:
return &logicResp{"fizz"}, nil
case divisibleBy5:
return &logicResp{"buzz"}, nil
default:
return &logicResp{strconv.FormatInt(int64(req.value), 10)}, nil
}
}
Бенчмарк
func BenchmarkValue(b *testing.B) {
var (
req = &fizzbuzz.ControllerReq{From: 1, To: 100}
resp *fizzbuzz.ControllerResp
err error
)
b.ResetTimer()
for i := 0; i < b.N; i++ {
resp, err = fizzbuzz.ValueController(context.TODO(), req)
}
_, _ = resp, err
}
func BenchmarkPointer(b *testing.B) {
var (
req = &fizzbuzz.ControllerReq{From: 1, To: 100}
resp *fizzbuzz.ControllerResp
err error
)
b.ResetTimer()
for i := 0; i < b.N; i++ {
resp, err = fizzbuzz.PtrController(context.TODO(), req)
}
_, _ = resp, err
}
Результат:
goos: windows
goarch: amd64
pkg: articles/src/fizzbuzz
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkValue-16 323662 3313 ns/op 4227 B/op 4 allocs/op
BenchmarkPointer-16 204608 5862 ns/op 5811 B/op 103 allocs/op
Как можно видеть, реализация с передачей по значению выделяет намного меньше памяти, делает меньше аллокаций и работает быстрее. Разумеется, это выдуманный пример, но реализовывать огромное приложение для демонстрации разницы производительности было бы непрактично.
Расширяемость
Под расширяемостью я понимаю способность кода не требовать модификаций при изменении требований или связанного с ним кода.
Например, если мы добавим в структуру мьютекс, то передавать его копии будет уже невозможно, и в таком случае старый код может потребоваться переписать. С другой стороны, большинство обрабатываемых приложением данных не требуют конкурентного доступа, а оттого, как правило, не будут содержать поля, не позволяющие копирование.
Консистентность
Практически любой репозиторий обязательно будет иметь параметры или возвращаемые значения, являющимися как указателями, так и значениями. Поэтому говорить о желании сделать код более единообразным не получится — целые числа и строки всё равно будут передаваться по значению, а структуры с мьютексами — по указателю.
Наоборот, передача параметров и возврат значений двумя способами могут повысить читаемость кода, т. к. будут обусловлены особенностями передаваемой структуры и её использованием (наличием мьютекса, необходимостью передавать по указателю для изменения или сохранения указателя на значение), а не принятым в команде соглашением всё передавать по указателю. Передача по указателю будет выделяться и иметь необходимость, вместо того чтобы быть выбором по умолчанию.
Потенциальные ошибки
Повсеместное использование указателей в качестве параметров приводит к выбору: необходимо либо проверять каждый параметр на равенство nil, либо допускать, что произойдёт паника при попытке разыменования указателя nil.
Передача по значению может привести к случайному копированию и изменению значений полей у копии, а не у оригинального значения, но такие вещи легко обнаруживаются линтерами, на ревью и здравым смыслом. Не утверждаю, что такие ошибки исключены полностью, но для меня они всегда оказывались более редкими, менее фатальными и легко обнаруживались второй парой глаз.
