Как провести эскейп анализ?

Question

[Илья]

Мне интересно, не утекает ли память при такой конструкции:
У меня есть функция, которая растеризует прямую линию между двумя заданными точками (r0, c0)-(r1, c1), также принимая указатель на буфер, в который записываются координаты ( type point struct{ r, c int}). Возвращает буфер (не указатель). В теле функции он обычно разростается до определенного порога элементов через append.

func line(r0, c0, r1, c1 int, buffer *[]point) []point {
    *buffer = (*buffer)[:0]
    ...
    *buffer = append(*buffer, point{ ... })
    ...
    return *buffer
}

Так вот, если посмотреть на адреса входящего и выходящего слайса, то они закономерно изменяются (до опр. порога). Но меня интересует, как компилятор воспринимает такую конструкцию и нет ли утечек памяти?

UPD: Перефразирую вопрос. Не ускальзывают ли предшествующие слайсы (которые малого размера) в кучу и не теряются ли там. Т.к. буфер заменяется в результате роста элементов и слайсы выводятся из ф-ции для дальнейшего использования в общую область видимости.

Comments

[Евгений Мамонов]

Указатель на слайс особо нет смысла передавать, это скорее вызовет больше нагрузки на сборщик мусора, чем даст пользы. Попробуйте сделать бенчмарки с указателем и без и посмотрите что будет быстрее и где будет меньше аллокаций, 99%, что без указателя будет быстрее.

Вот как он выглядит слайс в исходниках Go

type slice struct {
	array unsafe.Pointer
	len   int
	cap   int
}

[Илья]

Евгений Мамонов, когда мы изменим слайс посредством append в теле ф-ции, то он изменит только входящую копию, а не сам слайс. А мне нужно, что бы буфер изменялся inplace (для дальнейшего переиспользования) и для удобства возвращался как значение. Если иначе, то для меня лично поведение кода будет еще более неопределённо

[Илья]

Евгений Мамонов, Вы напечатали адрес указателя. Чтобы глянуть адрес ссылки на слайс нужно убрать амперсанд. Но в целом подход то верный для переиспользования, но мне хочется чтоб inplace, т.е. без возврата из ф-ции слайс изменялся

Answer 1

[Александр Павлюк]

"Утечка памяти" — это некорректный термин здесь. Скорее всего вы хотите, чтобы было поменьше аллокаций, соответственно, больше производительность.
1. Лучше слайс на вход передавать не указателем. Если слайс нужно изменять внутри функции, то хорошей практикой будет просто возвращать измененный слайс.
2. Если у вас там много append-ов, то надо не забывать заранее аллоцировать внутри слайса место под эти аппенды, если известно их количество.
Например, если знаете, что точек в буфере будет 20, то делайте: buffer = make([]point,0,20)
3. Всегда можно сравнить несколько разных реализаций путем написания бенчмарков. https://scene-si.org/2017/06/06/benchmarking-go-pr...
Если будете использовать ReportAllocs, то как раз увидите, в каком варианте у вас больше аллокаций.

Comments

[Илья]

Скорее я хотел спросить, не ускальзывают ли предшествующие слайсы (которые малого размера) в кучу и не теряются ли там. Ибо буфер заменяется в результате роста элементов и слайсы выводятся из ф-ции для дальнейшего использования в общую область видимости.
В целом основная механика переиспользования здесь в этом и заключается, только я забыл добавить в начале ф-ции *buffer = (*buffer)[:0].

[Илья]

Ну разыменовать указатель по сравнению со сложностью построения растра линии совсем уж незначительная операция, а удобство в том что не нужно каждый раз переназначать буфер в вызывающем коде. Экономия 1 строчки как минимум)

[Александр Павлюк]

Илья, предшествующие слайсы ускальзывают и удаляются потом сборщиком мусора.

Дело не в разыменовывании указателя, а в том, что вы создаете лишний указатель, который попадет в пул объектов и будет отслеживаться сборщиком мусора, тратя на это ресурсы.