Краткий ответ

Инлайнинг может сделать контекст вызова доступным для escape analysis. После встраивания компилятор иногда видит, что временный объект не покидает вызывающую функцию, и размещает его в стеке либо устраняет саму аллокацию; без инлайнинга тот же объект может быть признан убегающим и попасть в кучу.

Это не гарантия: результат зависит от версии Go, формы кода и последующих оптимизаций. Проверять фактическое решение следует диагностикой компилятора, а не предположением по исходному коду.

Исторический контекст

Раздельный вызов небольшой функции скрывает от оптимизатора связь между созданием значения и его использованием. Инлайнинг появился как общий способ уменьшить стоимость вызовов и одновременно открыть тело функции для дальнейшего анализа.

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

Постановка проблемы

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

Отключение оптимизаций ради диагностики также способно исказить результаты бенчмарка. Поэтому сравнивать вариант с инлайнингом и вариант с флагом -l как производственные реализации некорректно.

Подробное решение

Рассмотрим функцию, возвращающую указатель на объект:

package main

type Item struct {
    value int
}

func newItem() *Item {
    return &Item{value: 7}
}

func result() int {
    item := newItem()
    return item.value
}

Если newItem встроена в result, анализ видит, что указатель используется только для чтения поля и не возвращается, не записывается в глобальное состояние и не передаётся во внешнюю функцию. В таком случае объект может не считаться убегающим: компилятор способен разместить его на стеке, а последующие оптимизации — вообще свести вычисление к работе со значением 7.

Без инлайнинга анализ тела newItem рассматривается в менее выгодном для этого вызова контексте. Возвращаемый указатель потенциально передаётся вызывающему коду, поэтому компилятор может выбрать консервативное решение и разместить объект в куче. Это увеличивает число heap-аллокаций и потенциальную работу сборщика мусора.

Важно различать escape analysis и полное удаление объекта. Escape analysis отвечает прежде всего на вопрос, может ли объект находиться на стеке; устранение самой аллокации относится к последующим оптимизациям и не обязано произойти.

Инлайнинг ограничен размером функции, бюджетом оптимизатора, рекурсией и другими эвристиками. Даже успешное встраивание не обещает stack allocation: например, объект всё равно должен попасть в кучу, если его ссылка сохраняется после возврата из текущей функции.

Фактический результат можно изучать через диагностические сообщения компилятора, например с уровнем подробности -m=2. Такие сообщения показывают решения об escape, но их формулировка и детали могут меняться между версиями Go; для производительности дополнительно нужны бенчмарки и профили.

Ситуация из практики

В библиотеке преобразования данных небольшой helper возвращал указатель на временную структуру. В обычной сборке профилировщик показывал заметное число аллокаций, а эксперимент с отключённым инлайнингом давал ещё больше аллокаций.

Рассматривались три варианта:

отключить инлайнинг глобально — просто для проверки, но это ухудшает производительность и не является исправлением;
вручную переписать вызывающий код — может убрать аллокации, но повышает дублирование и стоимость сопровождения;
сохранить helper, проверить escape-диагностику и измерить обычную оптимизированную сборку — даёт наилучший баланс.

Выбрали третий вариант. После проверки выяснилось, что в целевой версии Go helper встраивался в горячем пути, а аллокация временного значения устранялась оптимизатором. Это подтвердили бенчмарком с -benchmem и профилем аллокаций; искусственное отключение инлайнинга в продуктовый код не переносили.

Что кандидаты часто упускают

Всегда ли отключение инлайнинга превращает временный объект в heap-аллокацию?

Нет. Компилятор может использовать другие сведения о потоке данных, межпроцедурные выводы или последующие оптимизации. Отключение инлайнинга лишь убирает один источник контекста и повышает вероятность менее точного решения; гарантировать конкретное размещение можно только по диагностике и измерениям.

Если объект размещён на стеке, исчезает ли любая стоимость его создания?

Нет. Stack allocation обычно дешевле heap allocation, но объект может требовать инициализации, копирования или обнуления. Кроме того, большой объект увеличивает используемый стек горутины, а рост стека может привести к копированию его содержимого.

Можно ли считать результат бенчмарка с флагом -l доказательством проблемы в рабочей сборке?

Нет. Флаг -l меняет кодогенерацию и сам способен создавать дополнительные аллокации, вызовы и косвенные эффекты. Он полезен для изоляции влияния инлайнинга, но итоговое решение нужно принимать по сборке с обычными оптимизациями, подтверждая причину escape-диагностикой, -benchmem и профилированием.