Как растёт слайс

Когда len == cap, рантайм зовёт growslice. Правило с Go 1.18: если требуемая длина больше удвоенной ёмкости, берём её саму; иначе при cap < 256 ёмкость удваивается, а начиная с 256 растёт по формуле newcap += (newcap + 3*256) / 4, то есть коэффициент плавно съезжает с 2x к 1.25x. До Go 1.18 порог стоял на 1024, и переход шёл ступенькой. Потом полученный размер в байтах округляется вверх до класса размеров аллокатора (roundupsize), поэтому реальный cap часто больше расчётного и цифры в cap() иногда кажутся «странными».

var s []int
prev := -1
for i := 0; i < 2000; i++ {
    s = append(s, i)
    if cap(s) != prev { fmt.Print(cap(s), " "); prev = cap(s) }
}
// Реальный вывод go1.27:
// 4 8 16 32 64 128 256 512 848 1280 1792 2560
//
// Дальше удвоение до 256, затем ~1.25x и округление до size class (см. выше).
// А вот начало неожиданное: последовательность стартует не с 1, а с 4. Это работа
// компилятора (Go 1.26+): слайс не убегает из функции, и первый массив он берёт
// на стеке, 32 байта, то есть 4 int. Если тот же append спрятать за
// //go:noinline-функцию, слайс убежит, и вернётся честное 1 2 4 8 16. Для []byte
// стартовая ёмкость по той же причине 32. Мораль: конкретные первые числа -
// деталь реализации, а не гарантия; гарантирована только амортизированная O(1)
// на элемент.

При этом старый массив становится мусором. Рост обходится в копирование, работу для сборщика и всплеск RSS: в момент перевыделения живы оба массива сразу.

Что даёт преаллокация в цифрах

func BenchmarkNoCap(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {                      // Go 1.24
        out := []int(nil)
        for i := 0; i < 10000; i++ { out = append(out, i) }
        _ = out
    }
}
func BenchmarkWithCap(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        out := make([]int, 0, 10000)
        for i := 0; i < 10000; i++ { out = append(out, i) }
        _ = out
    }
}
// go test -bench=. на go1.27 (Apple M4 Pro, arm64):
// BenchmarkNoCap-14      31342   36412 ns/op   357625 B/op   19 allocs/op
// BenchmarkWithCap-14    63304   20332 ns/op    81920 B/op    1 allocs/op

Устойчиво воспроизводится выигрыш по памяти: 357 КБ против 82 КБ (в 4,4 раза) и 19 аллокаций против одной. Лишнего набегает много: скопировано и выброшено около 260 КБ, втрое больше, чем нужно самому результату. А вот выигрыш по времени сильно зависит от машины: в замере выше это всего 1,8x, потому что десять тысяч итераций append сами по себе стоят дороже, чем перевыделения. На более медленной памяти разрыв заметно больше, но обещать «в разы быстрее» не стоит, лучше аргументируй аллокациями и нагрузкой на GC.

Ловушки

• make([]T, n) вместо make([]T, 0, n) встречается чаще всех. Первый вариант создаёт n нулевых элементов, и последующий append дописывает после них: получаем 2n элементов, из которых первые n нулевые. Ловят на собесе именно на этом.
• Подслайс делит массив с оригиналом. b := a[:2] имеет cap(b) == cap(a), и append(b, x) молча затрёт a[2]. Лечится full slice expression a[:2:2], который обрезает ёмкость и вынуждает append копировать.
• Маленький срез держит большой массив. head := data[:16] от 10-мегабайтного файла удерживает все 10 МБ живыми: GC видит указатель на начало объекта, а не на «использованную часть». Спасает slices.Clone или явное копирование.
• append возвращает новый слайс, и результат обязательно присваивать. Классический баг: слайс передают в функцию, которая делает append, а новое значение не возвращают. Иногда изменения видны (влезло в cap), иногда нет.
• Преаллокация вслепую тоже вредна. make([]T, 0, 1e6) на всякий случай гарантированно аллоцирует в куче (объект больше 32 КБ идёт в large object span мимо кэшей) и раздувает RSS. Ёмкость должна быть обоснованной: len входных данных, LIMIT запроса, размер батча.

// вырастить заранее под известную добавку (Go 1.21)
s = slices.Grow(s, need)   // гарантирует место под need элементов, без лишних копий
s = slices.Clip(s)         // cap = len: append больше не пишет в общий хвост; память не освобождается

strings.Builder

Конкатенация s += x в цикле копирует O(n²) байт: строки неизменяемы, и каждая итерация создаёт новую. Внутри strings.Builder лежит обычный []byte, который растёт по правилам append, а String() отдаёт его без копирования через unsafe.String. Поэтому Builder нельзя копировать после первой записи: он хранит указатель сам на себя (copyCheck) и при копии паникует «strings: illegal use of non-zero Builder copied by value». go vet такую копию не ловит: его проверка copylocks знает только типы с методами Lock/Unlock вроде мьютексов.

var b strings.Builder
b.Grow(len(parts) * 8)          // одна аллокация вместо серии удвоений
for i, p := range parts {
    if i > 0 { b.WriteByte(',') }
    b.WriteString(p)
}
return b.String()               // без копии

// нужен []byte и переиспользование: bytes.Buffer или свой слайс
// склеить фиксированный набор: strings.Join (одна аллокация)

Разница с bytes.Buffer: Buffer умеет читать, а его Reset сохраняет выделенную память, поэтому он ложится в пул; Builder только пишет, его Reset память выбрасывает, зато String() бесплатен. Под «собрать строку и отдать» бери Builder, под «собрать байты, отправить, повторить» подойдёт Buffer или свой []byte.

Переиспользование буферов

// один буфер на весь цикл: cap сохраняется, аллокаций после прогрева ноль
buf := make([]byte, 0, 4096)
for _, r := range reqs {
    buf = buf[:0]
    buf = appendJSON(buf, r)
    w.Write(buf)
}

// Append-семейство вместо Sprintf: пишем в свой буфер, строку не создаём
buf = strconv.AppendInt(buf, id, 10)
buf = fmt.Appendf(buf, " %s\n", name)   // Go 1.19
// и на приёме тоже: json.Decoder/Encoder на потоке вместо Marshal в []byte

sync.Pool

Пул работает как кэш временных объектов, приколоченный к P: у каждого процессора есть приватный слот (доступ без синхронизации вообще) и разделяемая очередь, из которой другие P могут воровать. При сборке мусора пул не очищается сразу: живой набор уезжает в victim cache и умирает только на следующем цикле (Go 1.13), поэтому одна случайная сборка не обнуляет прогрев.

var bufPool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },   // всегда указатель, не значение
}

func handle(w http.ResponseWriter, r *http.Request) {
    b := bufPool.Get().(*bytes.Buffer)
    b.Reset()                       // обязательно: пришёл чужой мусор
    defer func() {
        if b.Cap() <= 64<<10 {      // порог: раздутый буфер обратно не кладём
            bufPool.Put(b)
        }
    }()
    render(b, r)
    w.Write(b.Bytes())
}

• Только указатели. Put(buf) со значением-слайсом кладёт его в any, а упаковка сама по себе аллоцирует, и staticcheck ругается на это кодом SA6002. Кладём *bytes.Buffer или *[]byte.
• Reset обязателен, иначе данные утекают между запросами (в худшем случае в тело ответа попадёт чужой ответ, а это уже уязвимость).
• Порог на размер. Без него один запрос на 200 МБ оставит в пуле 200-мегабайтный буфер, и пока пул в работе, этот буфер ходит по кругу и держит память. Ровно этот приём есть в fmt и net/http.
• Пул не нужен для мелочи. Маленький объект из mcache выделяется за несколько наносекунд; Get/Put плюс промахи кэша могут стоить дороже. Пул окупается на крупных (килобайты), короткоживущих и часто создаваемых объектах.
• После Put объект использовать нельзя: его уже могла забрать другая горутина. Типичная ошибка: defer pool.Put(b) и возврат b.Bytes() наружу.

Конверсии string и []byte

Обычные []byte(s) и string(b) копируют, и это цена неизменяемости строк. Но компилятор знает несколько случаев, где копия не нужна, и убирает её сам. Знать этот список важнее, чем уметь писать unsafe:

m[string(b)]                       // лукап по []byte без аллокации строки
if string(b) == "ping" { }         // сравнение без аллокации
switch string(b) { case "get": }   // тоже
for i, c := range []byte(s) { }    // обход байтов без копии; range string(b) копирует
w.Write([]byte(s))                 // здесь копия будет; io.WriteString(w, s) - нет, если у w есть WriteString

// ручные конверсии без копии (Go 1.20+), только для горячего пути
func b2s(b []byte) string { return unsafe.String(unsafe.SliceData(b), len(b)) }
func s2b(s string) []byte { return unsafe.Slice(unsafe.StringData(s), len(s)) }

Откуда берётся padding

На amd64 и arm64 выравнивание 8 у указателей, int, int64, float64; 4 у int32/float32/rune; 2 у int16; 1 у byte, bool, int8. Смещение поля обязано быть кратно его выравниванию, а размер всей структуры кратен максимальному выравниванию среди полей (чтобы в массиве второй элемент тоже лёг ровно). Отсюда и «хвостовой» padding в конце.

type Bad struct {   // 24 байта
    A bool          // offset 0,  +7 padding
    B int64         // offset 8
    C bool          // offset 16, +3 padding
    D int32         // offset 20
}
type Good struct {  // 16 байт
    B int64         // 0
    D int32         // 8
    A bool          // 12
    C bool          // 13, +2 хвостового padding
}

fmt.Println(unsafe.Sizeof(Bad{}), unsafe.Sizeof(Good{}))   // 24 16
fmt.Println(unsafe.Offsetof(Bad{}.D), unsafe.Alignof(Bad{}))     // 20 8

$ go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
$ fieldalignment ./...
/app/model.go:12:12: Order has size 24 but the optimal size is 16 leading to a waste of 8 bytes (33%)
$ fieldalignment -fix ./...       # переставит поля сам

$ go build -gcflags=-m=2 ./...    # подробно: почему убегает и почему не инлайнится

Когда это вообще имеет значение

Сэкономленные 8 байт на структуре, которых в программе три штуки, ничего не решают. Смысл появляется, когда таких значений миллионы: срез из миллиона Bad занимает 24 МБ против 16 МБ, то есть 8 МБ чистой пустоты и в полтора раза больше памяти, которую обход тянет через кэш. Второй случай: структура летит по сети или в очередь миллионами раз в секунду. В обычном бизнес-коде это микрооптимизация последнего уровня, и ломать логическую группировку полей ради 8 байт на десяти объектах не стоит: размен плохой.

Ловушки

• Пустая структура в конце. Поле типа struct{} последним в структуре получает padding до 1 байта: иначе указатель на него смотрел бы за границу объекта, а такие указатели рантайм не допускает. Если struct{} стоит не последним, размер не меняется.
• Размер не равен «сумме полей». У string 16 байт (указатель + длина), у []T 24, у interface{} и любого интерфейса 16, у map/chan/func 8. Их содержимое лежит отдельно в куче, unsafe.Sizeof его не считает.
• Не путать выравнивание с числом указателей. Иногда важнее не размер, а то, что структура вообще без указателей попадает в noscan-класс и не сканируется сборщиком.

Зачем это нужно

Сам вызов на современном процессоре стоит единицы наносекунд, и ради этого никто бы не старался. Инлайн ценен другим. Тело оказывается в контексте вызывающего, и дальше работают остальные проходы: escape analysis видит, что указатель никуда не утёк, и оставляет объект на стеке; константы сворачиваются; проверки границ удаляются, потому что индекс известен; мёртвые ветки выкидываются. Отсюда и типичная картина: убираешь //go:noinline, и заодно исчезает аллокация, которой в этой функции вроде бы неоткуда взяться.

Бюджет

Стоимость считают по узлам AST: обычная операция стоит 1, вызов другой функции целых 57 (inlineExtraCallCost), а лимит равен 80 (inlineMaxBudget). Выходит, функция с двумя неинлайнящимися вызовами внутри почти наверняка сама в бюджет не влезет. При этом с Go 1.12 работает mid-stack inlining: функцию, которая сама кого-то вызывает, всё равно заинлайнят, если её собственная стоимость (вместе с уже подставленными вызовами) укладывается в бюджет.

Что мешает

• Тело дороже 80 узлов, в выводе function too complex: cost N exceeds budget 80.
• Рекурсия ограничивает глубину: рекурсивную функцию подставят на один уровень, дальше цикл не разворачивается (до Go 1.24.3 прямая рекурсия запрещала инлайн совсем).
• recover() в теле.
• defer и go в теле (unhandled op DEFER).
• Вызов через интерфейс или через переменную-функцию: цель неизвестна на этапе компиляции, инлайнить нечего. Компилятор умеет девиртуализовать, когда конкретный тип очевиден локально, но в общем случае не справляется.
• Явный запрет //go:noinline: его ставят в бенчмарках, чтобы компилятор не выкинул измеряемый код целиком.
• Функции на ассемблере и часть рантайм-функций.

$ go build -gcflags='-m -m' ./pkg 2>&1 | grep -i inlin
pkg/h.go:10:6: can inline small with cost 6 as: func(int) int { return x * 2 + 1 }
pkg/h.go:18:6: cannot inline big: function too complex: cost 90 exceeds budget 80
pkg/h.go:24:6: cannot inline cleanup: unhandled op DEFER
pkg/h.go:31:6: can inline fact with cost 71 as: func(int) int { if n <= 1 { return 1 }; return n * fact(n - 1) }
pkg/h.go:26:14: inlining call to small
pkg/h.go:35:17: inlining call to fact

$ go build -gcflags='-m -l' ./pkg     # -l выключает инлайн: видно "честные" решения escape analysis
$ go build -gcflags='-l -l -l -l'     # наоборот, агрессивнее (для экспериментов)

Приём: быстрая обёртка плюс холодный хвост

// обёртка укладывается в бюджет и инлайнится в вызывающего
func (c *Cache) Get(k string) (V, bool) {
    if v, ok := c.fast[k]; ok { return v, true }   // горячий путь: пара операций
    return c.getSlow(k)                            // редкий путь вынесен
}

//go:noinline
func (c *Cache) getSlow(k string) (V, bool) {
    // блокировки, промах кэша, поход в БД - сколько угодно кода,
    // он не мешает инлайну Get, потому что живёт в другой функции
}

Ровно так устроены стандартные sync.Mutex.Lock (быстрый CAS плюс lockSlow) и sync.Once.Do (проверка флага плюс doSlow). Это единственная перестройка кода ради инлайна, которую стоит делать сознательно: она заодно и читается лучше, потому что быстрый путь видно сразу.

Как включить

# 1. снять профиль с прода под реальной нагрузкой
$ curl -so cpu.pprof 'http://localhost:6060/debug/pprof/profile?seconds=60'

# 2. положить рядом с main-пакетом под именем default.pgo и закоммитить
$ cp cpu.pprof ./cmd/api/default.pgo

# 3. всё; -pgo=auto включён по умолчанию с Go 1.21
$ go build ./cmd/api
$ go build -pgo=./cpu.pprof ./cmd/api    # явный путь
$ go build -pgo=off ./cmd/api            # выключить (например, для сравнения в бенчмарке)

# профили с нескольких подов лучше слить в один
$ go tool pprof -proto pod1.pprof pod2.pprof pod3.pprof > default.pgo

Что компилятор делает с профилем

• Инлайн горячих вызовов. Для call site, отмеченных в профиле как горячие, бюджет поднимается до 2000 против обычных 80, и «слишком сложные» функции в горячем месте всё-таки подставляются.
• Девиртуализация. Если в профиле видно, что 95% вызовов io.Writer.Write уходят в *os.File, компилятор ставит прямой вызов с проверкой типа и запасной веткой на общий случай. А прямой вызов дальше можно ещё и заинлайнить, так что эффекты складываются.
• Выравнивание горячих циклов. С Go 1.23 на amd64 и 386 заголовки горячих циклов выравниваются в коде, по замерам команды Go это ещё 1–1,5%. Переставлять блоки и функции по профилю, как BOLT, компилятор Go пока не умеет.

Оговорки, за которые ставят плюс

• Профиль должен быть репрезентативным. Снятый с ноутбука на синтетическом тесте профиль оптимизирует не тот код. Нужен прод (или staging с боевым трафиком) под нагрузкой, желательно усреднённый по нескольким инстансам и снятый не в момент деплоя.
• Устаревший профиль не ломает сборку. Если функции переименовали и код переписали, компилятор просто не найдёт совпадений и соберёт как обычно. Хуже не станет, пропадёт только выигрыш. Обычно профиль обновляют отдельной джобой в CI, например еженедельно.
• Итеративная стабильность. Профиль, снятый с PGO-сборки, годится для следующей PGO-сборки: команда Go специально проверяет, что бинарь не «расходится» от поколения к поколению.
• Платишь временем компиляции. С Go 1.23 это единицы процентов (раньше крупные сборки замедлялись вдвое и больше), немного растёт и размер бинарника. Кэш сборки при смене профиля инвалидируется целиком.

Порядок действий

1. Есть ли проблема? Нарушенный SLO, растущая стоимость железа, жалоба. Без цифры задачи нет. «Кажется, тут медленно» ещё не задача.
2. Где именно? Профиль, а не интуиция. По закону Амдала функция, занимающая 2% времени, даже ускоренная вдвое, даст 1%. Это не окупает ни дня работы, ни усложнения кода.
3. Алгоритм и архитектура. Убрать N+1 запрос, добавить индекс, закэшировать, сбатчить, не делать работу вовсе. Здесь лежат разы. Быстрее всего работает код, который не выполняется.
4. Аллокации. Преаллокация, переиспользование буферов, меньше указателей, меньше лишних копий. Здесь лежат десятки процентов, и заодно снижается нагрузка на GC.
5. Микрооптимизации. Порядок полей, инлайн, PGO, unsafe. Здесь лежат единицы процентов.
6. Проверить в проде. Бенчмарк доказывает, что функция стала быстрее; что стало быстрее приложение, доказывает только метрика после выката.

Измерять - значит измерять статистически

$ go test -run=^$ -bench=Encode -benchmem -count=10 > old.txt
# ... правка ...
$ go test -run=^$ -bench=Encode -benchmem -count=10 > new.txt
$ benchstat old.txt new.txt
          │   old.txt    │               new.txt               │
          │    sec/op    │   sec/op     vs base                │
Encode-14   128.65n ± 3%   36.98n ± 1%  -71.25% (p=0.000 n=10)

          │  old.txt   │              new.txt               │
          │    B/op    │   B/op     vs base                 │
Encode-14   80.00 ± 0%   0.00 ± 0%  -100.00% (p=0.000 n=10)

          │  old.txt   │               new.txt               │
          │ allocs/op  │ allocs/op   vs base                 │
Encode-14   5.000 ± 0%   0.000 ± 0%  -100.00% (p=0.000 n=10)

Один прогон «до» и один «после» ничего не доказывают: разброс на ноутбуке легко даёт 10–15%. Нужны -count и benchstat с p-value. Если p > 0.05 или дельта меньше разброса, изменения нет и правку откатываем, даже если она «явно быстрее по логике».

Компромисс с читаемостью

• Оптимизируй только измеренное. Горячего кода в сервисе обычно 1–2%; остальные 98% должны быть максимально скучными и понятными.
• Локализуй сложность. Хитрость прячется за обычным интерфейсом: снаружи Encode(w, v), а внутри пул, буфер и unsafe. Тогда её читает один человек, а не весь отдел.
• Комментарий с цифрами обязателен. Не «так быстрее», а «был Sprintf: 129 нс, 5 аллокаций; стало 37 нс, 0 аллокаций; см. BenchmarkEncode». Без этого следующий человек «упростит» код обратно и будет прав, потому что обоснования нет.
• Бенчмарк остаётся в репозитории. Он защищает от регрессии: без него оптимизация протухнет за пару рефакторингов.
• Ограничивай радиус. unsafe и ручные трюки держи внутри одного пакета, не в API и не в доменных типах.