Дженерики в Go: одиннадцать типов, шесть тел кода и метод, до которого всё равно идут через словарь

Одно тело на форму, а не на тип

Компилятор порождает код не под каждый подставленный тип, а под форму — размер, выравнивание и расположение указателей внутри. Всё, чего телу не хватает, чтобы знать конкретный тип, передаётся скрытым аргументом — словарём.

Считать это не надо на глаз: bench/gogenerics/shapes.go собирает подопытный пакет и читает таблицу символов через go tool nm. Там видно и тела (main.AnyBox[go.shape.*uint8]), и словари (main..dict.AnyBox[*main.A]).

Три правила, и все три на картинке:

• указатели сливаются, если ограничение — набор методов;
• именованный тип берёт форму базового (Celsius, Meters, float64 — одно тело);
• int64 и float64 не сливаются, хотя оба по восемь байт, — и так задумано: у них разные операции.

Почему метод всё равно вызывается косвенно

Раз три указателя делят одно тело, это тело не знает, чей метод звать. Подставить адрес при сборке нельзя — он берётся из словаря.

Дженерик не даёт скорости прямого вызова — это главное и это не меняется. А вот отношение дженерика к интерфейсу меняется: на прежнем прогоне статьи они шли вровень, здесь дженерик заметно дешевле. Выбирать по этому отношению нельзя.

Зато четырёхкратную разницу можно разложить. Поставим методу //go:noinline, чтобы прямой путь тоже делал настоящий вызов:

Прямой вызов без встраивания подорожал с 321 до 1 143 — значит, встраивание стоило около 822 нс из 1 021, на которые дженерик отставал. Примерно четыре пятых разницы — это потерянное встраивание, а не косвенность.

Но только если в ограничении есть методы

Байты и выделения совпадают точно, а времена лежат внутри разброса раундов. Для [T ~int64] или [T ordered] тело компилируется под конкретную форму, и от дженерика в машинном коде не остаётся ничего.

Правило, которое стоит унести: не «дженерики быстрые» и не «дженерики медленные», а посмотрите на ограничение.

Настоящая цена — не дженерик, а any

Срез из пар «дескриптор типа, указатель на значение» — по 16 байт на элемент — плюс коробка на каждое значение: 16 384 плюс 8 000 и есть 24 384. Вот от чего дженерик спасает в разы.

Оговорка: само преобразование в any кучи не требует. Уедет значение в кучу или нет, решает анализ убегания конкретного кода и конкретной версии компилятора. Здесь значения складываются в срез и живут дальше — уезжают. В замере одного сравнения то же преобразование не даёт ни одного выделения.

И ещё одна: 16 байт на элемент — это раскладка данной сборки под linux/amd64, а не контракт any.

Чем измерено

Все числа выше сняты на go1.24.7 linux/amd64, Intel Xeon 2,10 ГГц, GOMAXPROCS = 2, семью чередующимися раундами; прогон целиком лежит в bench/gogenerics/runs/cost.txt. Число тел кода и словарей — bench/gogenerics/shapes.go.

Язык при этом ушёл дальше: в Go 1.26 сняли запрет на самоссылку в ограничении, в Go 1.27 появились обобщённые методы — и то и другое здесь проверено компилятором, а не взято из примечаний к выпуску. Замеры на 1.27 повторены тоже: таблица форм совпала побайтово, а в паре прогонов на одной машине диапазоны двух toolchain перекрылись в каждой строке. То есть 1.27 в этих нагрузках не изменил ничего.

Совпадения ваших времён с этими ждать не надо: ждать надо совпадения соотношений внутри одной таблицы — и то не всех, как показывает пара «дженерик и интерфейс». Число тел кода секундомером не меряется, его даёт таблица символов, и при том же исходнике, той же версии компилятора и той же целевой конфигурации оно будет тем же.

Три слоя, которые в разговорах про дженерики слипаются

Почти весь спор «дженерики в Go быстрые или медленные» держится на том, что три разных вопроса задаются как один. Развести их надо с самого начала, потому что ответы у них разной прочности:

Статья идёт ровно в этом порядке: сначала что дженерик выражает, потом какое множество типов задаёт ограничение и что оно разрешает телу, потом нужен ли дженерик вообще, потом как всё это сделано в go1.24.7 — и только в конце, сколько оно стоило на нашей машине.

Порядок не косметический. Прочитанное в обратную сторону — «замерили 4,18, значит дженерики вчетверо дороже» — это вывод о языке из наблюдения за машиной, и неверен он ровно настолько, насколько велика разница между слоями. Насколько она велика, видно в конце: одно и то же отношение между дженериком и интерфейсом на двух экземплярах одной машины вышло разным.

Из чего состоит дженерик

Начать стоит не с компилятора, а с того, что вообще написано на бумаге. Пять слов, которые дальше используются постоянно, — и все пять видны в одной строчке:

Два вызова одной функции — Max(10, 20) и Max(1.5, 2.5) — дают int и float64. Никакого приведения, никакого any, конкретный тип сохранён и на входе, и на выходе. Это и есть то, ради чего параметры типа появились, и это утверждение о языке: оно верно на любой реализации Go.

Параметры типа бывают не только у функций:

type Box[T any] struct {
    Value T
}
 
b := Box[string]{Value: "s"}

Вот тут и возникает вопрос, с которого обычно начинают, — и хорошо, что он возникает вторым, а не первым: сколько машинных версий этого кода должен породить компилятор? Одну на каждый подставленный тип? Одну на всех? Ответ лежит не в языке, а в реализации, и разбирается в своей части статьи, ниже.

А сначала — вторая половина той строчки, cmp.Ordered.

Ограничение задаёт множество типов, а множество типов задаёт операции

Цепочка, из которой механически следует всё остальное:

1. ограничение задаёт
2. множество типов — какие T разрешены, — а оно задаёт
3. операции, разрешённые телу функции.

Последняя стрелка — не метафора. Тело может делать со значением типа T ровно то, что разрешено каждому типу из множества, и ни на одну операцию больше.

Четыре ограничения, которые встречаются чаще всех, стоит прочитать сначала как язык, а не как форму кода:

Заметьте, что comparable и объединение — это не «интерфейсы» в привычном смысле: значением такого типа быть нельзя. Различение разбирается прямо ниже, и оно же потом объяснит самое неожиданное наблюдение статьи.

Что ограничение разрешает телу, а что запрещает

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

Отсюда механическое следствие, которое видно на двух ошибках компиляции (bench/gogenerics/constraints.go):

v.Name undefined (type T has no field or method Name)
invalid operation: operator + not defined on a (variable of type T constrained by Named)

Ограничение-множество (~int | ~float64) даёт операторы, но не даёт методов. Ограничение-поведение (interface { Name() string }) даёт метод, но не даёт операторов. И совместить их объединением нельзя — спецификация запрещает:

Совместить можно пересечением: interface { ~int; Name() string } — и тогда доступны и оператор, и метод. Проверено: работает.

Базовый интерфейс и общий: почему это не одно слово «интерфейс»

Здесь же лежит различение, из-за которого путаются в самом начале, — и то самое, которым ниже будет объясняться слияние указателей. Спецификация делит интерфейсы надвое:

Проверяется это компилятором мгновенно:

type Number interface{ ~int | ~float64 }
 
var x Number                    // не компилируется
func Sum[T Number](a, b T) T    // компилируется

Сообщение компилятора дословно (bench/gogenerics/constraints.go, случай 4):

cannot use type Number outside a type constraint: interface contains type constraints

Отсюда две вещи сразу. Первая: ограничение — не значение. Когда T ограничен Stringer, внутри тела нет никакой интерфейсной переменной; есть конкретный тип, о котором известно, что у него есть метод. Вторая: именно принадлежность к базовым и решает форму, а число методов — нет. Но это уже про компилятор, и проверяется это ниже, таблицей из шести ограничений.

Тильда: почему ~int64, а не int64

~ встречалась выше как часть синтаксиса, и пора сказать, что она означает. Ограничение из одного типа задаёт множество из одного элемента:

Тильда расширяет его до всех типов с таким базовым:

Практическая разница — вот эта (bench/gogenerics/tilde.go):

type Exact  interface { float64 }
type Under  interface { ~float64 }
type Celsius float64
 
ScaleExact(Celsius(20))  // не компилируется
ScaleUnder(Celsius(20))  // работает

Компилятор при этом сам подсказывает, чего не хватает:

Celsius does not satisfy Exact (possibly missing ~ for float64 in Exact)

То есть без тильды ограничение отсекает весь ваш доменный код: type UserID int64 не подойдёт под [T int64], type Celsius float64 — под [T float64], type Seconds int — под [T int]. Почти всегда нужна тильда.

У самой тильды два ограничения, и оба спецификация называет прямо: в терме ~T базовый тип T должен быть самим T (то есть ~MyInt при type MyInt int не бывает) и не может быть интерфейсом. Проверено — оба случая дают ошибку компиляции:

invalid use of ~ (underlying type of MyInt is int)
cannot satisfy Bad (empty type set)
invalid use of ~ (error is an interface)

Первый случай даёт две строки: ограничение с запрещённым термом становится пустым множеством, и следом падает всякая попытка его удовлетворить.

И то же, что и у вывода типов выше: тильда расширяет множество, но не стирает имя. ScaleUnder(Celsius(20)) возвращает main.Celsius, а не float64.

Что выводится, а что придётся написать руками

Вывод в первой строчке статьи назван и на этом оставлен. Именно из-за него дженерики на письме выглядят как обычные функции, и у него есть закрытый список случаев, где он работает. Спецификация описывает его так:

Ключевое слово — «из контекста». Список контекстов в спецификации закрытый:

Присваивания результата в этом списке нет — и отсюда самый частый случай, когда компилятор просит написать параметр явно. Проверено на go1.24.7 (bench/gogenerics/inference.go); ниже отказы компилятора дословно, снята только позиция в файле перед сообщением:

in call to Zero, cannot infer T (declared at ./main.go:3:11)
in call to Make, cannot infer T (declared at ./main.go:3:11)
cannot use generic type Box[T any] without instantiation
in call to Pair, mismatched types untyped int and untyped string (cannot infer T)

Правило, из которого всё это следует, простое: выводится то, что видно в аргументах. У Zero[T]() T аргументов нет — выводить не из чего. У обобщённого типа (не функции) вывода нет вовсе: Box[T] надо инстанцировать.

Отдельно стоит нетипизированная константа. Спецификация ставит приоритет прямо:

Разница видна на двух вызовах одной функции Sum[T ~int | ~float64](a, b T) T. Пока оба операнда — нетипизированные константы, расширению ничто не мешает: Sum(1, 2.5) даёт float64. Но стоит одному операнду стать типизированным (var i int, вызов Sum(i, 2.5)) — и T связан с int раньше, чем очередь дойдёт до константы:

cannot use 2.5 (untyped float constant) as int value in argument to Sum (truncated)

Падает здесь не вывод, а приведение константы к уже выведенному типу.

И приятная деталь, которую видно только запуском: вывод сохраняет именной тип. Для type Point []int вызов Map(p, f) даёт S = main.Point, а не []int — имя не теряется по дороге.

Нужен ли здесь дженерик вообще

До сих пор речь шла о том, что дженерик умеет. Вопрос, который на практике задают раньше всех остальных, — надо ли его тут применять. У авторов языка ответ сформулирован через противопоставление интерфейсу:

Из этого и из цепочки «ограничение → множество типов → операции» получается короткий разбор случаев:

один и тот же АЛГОРИТМ для семейства типов
    (сортировка, min/max, Map/Filter, суммирование)
    → дженерик

КОНТЕЙНЕР, которому всё равно, что внутри
    (стек, множество, кэш, очередь)
    → дженерик

надо СОХРАНИТЬ связь между типом входа и типом выхода
    (Keys(map[K]V) []K; Map([]T, func(T) U) []U)
    → дженерик: единственный из четырёх случаев,
      который интерфейсом не выражается вообще

у каждого типа своё ПОВЕДЕНИЕ, а код зовёт один метод
    (Read, String, Serve)
    → интерфейс

Третью строку чаще всего пропускают, а она и есть настоящая причина существования дженериков. func Keys(m map[any]any) []any компилируется и работает; чего в ней нет — так это связи между тем, что положили, и тем, что достали. Связь восстанавливается приведением у вызывающего, то есть проверкой в рантайме вместо проверки при сборке. Дженерик её сохраняет — и это свойство языка, не зависящее ни от версии компилятора, ни от машины.

Четвёртая строка — там, где дженерик не нужен, и совет авторов языка ровно про неё. Если реализация у каждого типа своя, ограничение с методами не даёт ничего, чего не даёт интерфейс: тогда интерфейс честнее и по смыслу.

А по цене вывод надо брать ровно в тех границах, в каких он измерен, и не шире; сам замер — в конце статьи. Измерено вот что: на одной нагрузке — тысяча объектов указательной формы, ограничение Namer, вызов Name() — дженерик не превратился в прямой вызов. Не измерено и потому не утверждается, что дженерик «стоит как интерфейс»: на прогоне, который лежит в bench/gogenerics/runs/cost.txt, он вышел заметно дешевле интерфейса, а на прежнем прогоне той же статьи — вровень с ним. Значит из замера следует одно: замена интерфейса на дженерик сама по себе не даёт ни прямого вызова, ни встраивания, ни девиртуализации, и рассчитывать на них при выборе API нельзя.

Множество типов без методов — то, ради чего дженерики и сделаны, и в трёх замерах оно не стоило ничего.

Что менялось в самом языке

Здесь проходит граница, которую в статьях про дженерики чаще всего стирают, а стирать её нельзя: состояние языка и toolchain замера — не одно и то же.

• Язык — Go 1.27. Цитаты ниже дословны, но ни одна возможность здесь не утверждается со слов документа: каждая проверена компилятором.
• Все таблицы статьи — go1.24.7. Опыт с формами и все замеры сняты на нём. Что из этого меняется на 1.27, разобрано в конце раздела: коротко — ничего.

Столбец «проверено» здесь означает буквально проверку: versions.go собирает каждый случай временным модулем тем же toolchain, которым запущен, и печатает ответ компилятора. Вот тот же файл, прогнанный дважды. На go1.24.7:

1. ВОЗМОЖНОСТИ ЯЗЫКА НА GO1.24.7, ПРОВЕРЕННЫЕ КОМПИЛЯТОРОМ
----------------------------------------------------------------------
  1. обобщённый псевдоним типа
     обещано: Go 1.24
     go.mod пробника: go 1.24
     | собралось

  2. ограничение ссылается на сам ограничиваемый тип
     обещано: Go 1.26
     go.mod пробника: go 1.26
     | go: go.mod requires go >= 1.26 (running go 1.24.7; GOTOOLCHAIN=local)

  3. у метода свои параметры типа
     обещано: Go 1.27
     go.mod пробника: go 1.27
     | go: go.mod requires go >= 1.27 (running go 1.24.7; GOTOOLCHAIN=local)

  4. у МЕТОДА ИНТЕРФЕЙСА параметров типа нет и в 1.27
     обещано: нигде: это граница, которую 1.27 не сдвинул
     go.mod пробника: go 1.27
     | go: go.mod requires go >= 1.27 (running go 1.24.7; GOTOOLCHAIN=local)

И тот же файл на go1.27.0:

1. ВОЗМОЖНОСТИ ЯЗЫКА НА GO1.27.0, ПРОВЕРЕННЫЕ КОМПИЛЯТОРОМ
----------------------------------------------------------------------
  1. обобщённый псевдоним типа
     обещано: Go 1.24
     go.mod пробника: go 1.24
     | собралось

  2. ограничение ссылается на сам ограничиваемый тип
     обещано: Go 1.26
     go.mod пробника: go 1.26
     | собралось

  3. у метода свои параметры типа
     обещано: Go 1.27
     go.mod пробника: go 1.27
     | собралось

  4. у МЕТОДА ИНТЕРФЕЙСА параметров типа нет и в 1.27
     обещано: нигде: это граница, которую 1.27 не сдвинул
     go.mod пробника: go 1.27
     | # probe
     | ./main.go:4:7: interface method must have no type parameters
     | ./main.go:4:27: undefined: F

Обратите внимание на случай 4: он собирается тем же toolchain, что и случай 3, и всё равно отказан. Про эту границу — ниже.

Псевдоним с параметрами — то, чего до 1.24 не было вовсе:

type Pair[A, B any] = struct {
    First  A
    Second B
}
 
p := Pair[int, string]{First: 1, Second: "s"}   // собирается на go1.24.7

В 1.26 сняли запрет, из-за которого ограничение нельзя было замкнуть на себя:

Пример оттуда же — ограничение «тип, умеющий складываться сам с собой»:

type Adder[A Adder[A]] interface {
    Add(A) A
}
 
func algo[A Adder[A]](x, y A) A {
    return x.Add(y)
}

А в 1.27 появилось то, чего у дженериков в Go не было с самого начала, — собственные параметры типа у метода:

Важна и вторая половина того же абзаца — граница, которую 1.27 не сдвинул:

Это не оговорка, а как раз тот случай 4 из прогона выше: метод интерфейса с собственным параметром типа компилятор 1.27 отказывается принимать, и отказ дословно такой —

./main.go:4:7: interface method must have no type parameters

То есть на выбор «дженерик или интерфейс», о котором вся вторая половина статьи, 1.27 влияет не так, как кажется на первый взгляд: он расширяет то, что можно выразить у конкретного типа, и ровно ничего не меняет в интерфейсах. Значит, и противопоставление, ради которого делался замер цены вызова, осталось тем же самым.

Там же расширен и вывод типов, которому посвящён отдельный раздел выше:

Тут напрашивается вывод, что раздел про вывод типов устарел, — и он неверен. Расширение 1.27 касается присваивания обобщённой ФУНКЦИИ переменной функционального типа; это случай, который и на 1.24.7 работал. Ни один из пяти отказов, приведённых в том разделе, к нему не относится: прогон inference.go на 1.27 даёт их дословно теми же, включая тот, где тип не выводится из цели присваивания результата.

Что из проверенного на go1.24.7 изменилось на 1.27

Ничего. Это стоит показать по частям, потому что «ничего» — тоже результат, и проверяется он по-разному для каждого слоя.

Опыт с формами кода — совпал побайтово. shapes.go на 1.27 даёт ту же таблицу символов: одиннадцать типов под any — шесть тел, под comparable — восемь, три указателя под Stringer — одно, объединение — три. Файлы прогонов лежат рядом (runs/shapes.txt и runs/shapes-go127.txt) и различаются одной строкой с номером версии. То есть группировка форм, которую спецификация не обещает, пережила три выпуска подряд.

Отказы компилятора в разделе про ограничения — тоже совпали побайтово. constraints.go на 1.27 печатает те же сообщения слово в слово.

Замеры времени — перекрываются во всех строках. Здесь нужна оговорка, которая важнее самих чисел: сравнивать между собой можно только два прогона, снятые на ОДНОЙ машине. Основные таблицы статьи сняты на одном экземпляре машины, а пара «1.24.7 против 1.27» — на другом, и её числа с таблицами статьи не сопоставляются вовсе. Внутри пары (runs/toolchain-go124.txt и runs/toolchain-go127.txt) сопоставляется всё, и результат такой: в каждой строке каждого блока диапазоны двух toolchain перекрываются. На этих нагрузках 1.27 не изменил ни времени, ни байтов, ни выделений.

А вот что эта пара сказала сверх заданного вопроса. На той машине блок 6 дал ×1,00: с запретом встраивания дженерик стоил РОВНО столько же, сколько прямой вызов, — и так на обоих toolchain. То есть там чтение адреса из словаря не стоило ничего измеримого, и всё отставание дженерика из блока 1 оказалось потерянным встраиванием, до последней наносекунды. На машине основных таблиц оставалось ещё 1,39. Складывать эти два наблюдения надо так: вклад встраивания — от четырёх пятых до всей разницы, вклад самой косвенности — от пятой части до нуля, и который из двух случаев ваш, решает машина, а не версия Go.

Три способа их сделать, и почему выбран третий

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

Вопрос, оставленный в начале, звучал так: сколько машинных версий тела должен породить компилятор из func Min[T Ordered](a, b T) T? Способов три, и у каждого своя беда.

Специализировать под каждый тип (как шаблоны в C++). Код получается идеальным: Min[int] — это две инструкции. Беда в объёме: тел столько, сколько разных подстановок, и в большой программе это заметно и в размере файла, и во времени сборки.

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

Промежуточный вариант, который и выбран: специализировать не под тип, а под форму. Форма — это то, чем тип выглядит для сборщика мусора:

Типов много, форм мало. Всё, чего телу не хватает, чтобы работать с конкретным типом, передаётся отдельно:

Дальше — что из этого выходит на практике, и всё это можно посчитать.

Сколько тел кода на самом деле

Числа здесь не выведены из документации, а сняты с готового двоичного файла. Программа bench/gogenerics/shapes.go собирает подопытный пакет и читает таблицу символов через go tool nm. Тела инстанциаций видны там прямо:

main.AnyBox[go.shape.*uint8]
main.AnyBox[go.shape.float64]
main.AnyBox[go.shape.int]
main.AnyBox[go.shape.int64]
main.AnyBox[go.shape.string]
main.AnyBox[go.shape.[2]int]

Шесть строк. А словарей рядом одиннадцать — по одному на каждый конкретный тип:

main..dict.AnyBox[*main.A]
main..dict.AnyBox[*main.B]
main..dict.AnyBox[*main.C]
main..dict.AnyBox[float64]
main..dict.AnyBox[main.Celsius]
...

Три указателя в одном теле — не совпадение и не оптимизация «на всякий случай». В компиляторе это одна функция и одно правило:

byte — это псевдоним uint8, поэтому в таблице символов форма называется *uint8. Из этих трёх предложений следует всё, что на картинке, — и в них уже стоит то самое слово: basic interface.

Указатели сливаются, если ограничение — базовый интерфейс. Слово «базовый» здесь не эпитет, а термин спецификации: базовый интерфейс — тот, чьё множество типов задано только методами. any — базовый (методов ноль), Stringer — базовый (один), интерфейс из двух методов — тоже. comparable базовым не является: в нём условие на сам тип. Поэтому под comparable те же одиннадцать типов дают не шесть тел, а восемь: группа указателей распадается, всё остальное остаётся как было.

Три ограничения — это три точки, и по трём точкам легко провести неверную линию: «дело в наличии методов» объясняет их ровно так же. Развести две формулировки может только ограничение, в котором методы есть, а базовым оно не является. Поэтому в подопытной программе их шесть:

Последняя строка и есть ответ: методы в ограничении есть, а слияния нет. Значит, дело не в них, а в том, задано ли ограничение только ими, — ровно как и написано в shapify. Числа сняты прогоном bench/gogenerics/shapes.go, который не просто печатает таблицу, а падает, если правило разойдётся с таблицей символов хотя бы на одном типе.

Именованный тип берёт форму базового. type Celsius float64 не даёт нового тела: его форма — float64. Отсюда практическое: заводить именованные типы поверх одного базового можно сколько угодно, на объём кода это не влияет.

Скаляры разных базовых типов не сливаются. int64 и float64 — по восемь байт, выравнивание одинаковое, указателей внутри нет. Для сборщика мусора это одна форма. Для компилятора — две.

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

Причина в словаре: у int и float64 разные операции, и в словарь пришлось бы класть разные реализации сложения. Даже int16 и int32 разведены — у них по-разному работают сдвиги.

А вот где реализация действительно расходится с документом — это указатели, и в другую сторону, чем можно подумать. Правило там записано без всяких условий:

or they are both pointer types (или когда оба они — указательные типы) — любые два указателя, без оговорок. А компилятор сливает их только под базовым интерфейсом: под comparable у каждого своя форма. Это ровно то, что видно на картинке, если переключить ограничение, — и то же самое стоит первым пунктом в заметке авторов shapify о том, чего они ещё не сделали:

То есть здесь реализация не грубее документа, а тоньше.

Что это значит для вызова метода

Вот тут интуиция подводит систематически. «Заменю интерфейс на дженерик и получу прямой вызов» — правка, которую делают ради скорости и которая скорости не даёт.

Логика простая, и она вся уже на предыдущей картинке. Раз у Named[T Stringer] все указатели делят одно тело, это тело не знает, чей метод звать. Значит, подставить адрес (*user).Name в код при сборке нельзя. Адрес лежит в словаре, и вызов идёт через него — косвенно.

Замерено на тысяче вызовов, семь чередующихся раундов, в столбце — диапазон по раундам:

1. ВЫЗОВ МЕТОДА У ТЫСЯЧИ ОБЪЕКТОВ
----------------------------------------------------------------------
                                     нс/оп         Б/оп   выдел.  кратно
  напрямую, []*user                  321-328       0      0       x1.00
  дженерик, [T Namer]                1342-1462     0      0       x4.18
  интерфейс, []Namer                 2185-2243     0      0       x6.81

Дженерик не даёт скорости прямого вызова — это главное, и это не меняется от машины к машине. А вот дальше начинается место, где легко сказать лишнее, и статья его однажды уже сказала. Прежняя версия публиковала здесь 1 805 против 1 844 и делала вывод «дженерик даёт скорость интерфейса, разница 2 %». На экземпляре машины, где снят прогон выше, этой двухпроцентной близости нет вовсе: дженерик оказался в полтора раза быстрее интерфейса. Тот же исходник, тот же go1.24.7, та же модель процессора в cpu: — и всё остальное в статье при этом стало быстрее на 10–40 %, а интерфейсный вызов один подорожал. Почему — этот замер не устанавливает; устанавливает он другое, и это стоит унести с собой: цена косвенного вызова — самое непереносимое число во всей статье, и строить на отношении «дженерик к интерфейсу» выбор в коде нельзя.

Зато пятикратное отставание от прямого вызова разложить на слагаемые можно, и теперь оно разложено. Прежде здесь стояло предположение: «скорее всего, дело не только в косвенности — прямой вызов компилятор ещё и встраивает». Проверка предположения стоит одной директивы.

Сколько из четырёхкратной разницы — потерянное встраивание

//go:noinline на методе убирает у прямого пути ровно одно преимущество: теперь он тоже делает настоящий вызов. Всё прочее — тип, обход, объём работы — то же самое:

6. ТО ЖЕ, НО ВСТРАИВАНИЕ НА ПРЯМОМ ПУТИ ЗАПРЕЩЕНО
----------------------------------------------------------------------
                                     нс/оп         Б/оп   выдел.  кратно
  напрямую, //go:noinline            1143-1198     0      0       x1.00
  дженерик, [T Namer]                1585-1629     0      0       x1.39
  интерфейс, []Namer                 2198-2253     0      0       x1.92

Читается это так. Прямой вызов, лишённый встраивания, подорожал с 321 до 1 143 — то есть встраивание стоило около 822 нс на тысячу вызовов. Всё отставание дженерика от прямого вызова в блоке 1 — это 1 342 − 321 ≈ 1 021 нс. Значит, на встраивание приходится около четырёх пятых разницы, а на саму косвенность — оставшаяся пятая: как только прямой вызов действительно делается, дженерик отстаёт от него не в четыре раза, а в 1,39.

Контроль, по которому этот блок проверяется: интерфейсная строка. Интерфейсный вызов и так не встраивался, запрет у него ничего не отнимает, и его число обязано совпасть с блоком 1. Совпало — 2 185–2 243 против 2 198–2 253.

И сколько из отставания интерфейса — вообще не диспетчеризация

Есть ещё одно молчаливое допущение, которое блоки 1 и 6 делают вместе: будто у трёх строк всё, кроме способа вызова, одинаково. Не одинаково. []*user — это тысяча машинных слов, []Namer — тысяча пар «дескриптор типа, указатель», то есть вдвое больше данных на тот же обход. Отделяется это тем, что метод не зовётся вовсе: обе строки читают поле напрямую, у интерфейсной стороны через утверждение типа.

7. СКОЛЬКО ИЗ ОТСТАВАНИЯ ИНТЕРФЕЙСА — ВООБЩЕ НЕ ДИСПЕТЧЕРИЗАЦИЯ
----------------------------------------------------------------------
                                     нс/оп         Б/оп   выдел.  кратно
  чтение поля через []*user          317-348       0      0       x1.00
  чтение поля через []Namer          539-564       0      0       x1.70

Раскладка данных сама по себе стоит около 222 нс. Интерфейс отстаёт от честного прямого вызова на 2 198 − 1 143 ≈ 1 055 нс, и пятая часть этого — не диспетчеризация, а лишние восемь килобайт, которые процессор тащит через кэш.

Итог трёх блоков — не одно число, а порядок слагаемых: встраивание, диспетчеризация, раскладка данных, именно в этом порядке по величине. И проектный документ обе первые цены называет заранее, среди недостатков выбранного подхода: более осторожный анализ убегания и потеря встраивания там, где вызов метода не разрешается при компиляции.

Где дженерик не стоит ничего

Из предыдущего раздела напрашивается вывод «дженерики медленные». Он неверен, и вот почему.

Переключите вкладки. Первая — та, что выше: четырёхкратное отставание. А «чтение из среза», «построение среза» и «одно сравнение» — ноль разницы там, где ноль можно показать (в скобках диапазон по семи раундам):

Байты и выделения совпадают до единицы, а диапазоны времён перекрываются — значит разницы нет. Различает эти случаи не размер данных и не сложность кода. Различает одно: есть ли в ограничении методы.

• [T ~int64], [T ordered] — методов нет. Тело компилируется под форму int64, и в машинном коде от дженерика не остаётся ничего.
• [T Namer] — методы есть. Тело общее на все указатели, адрес из словаря.

Это и есть правило, которое стоит унести из статьи. Не «дженерики быстрые» и не «дженерики медленные», а: посмотрите на ограничение.

Настоящая цена, которую платят чаще всего

Она не в дженериках. Она в том, чем дженерики заменяют:

В этом замере (go1.24.7, linux/amd64) интерфейсное значение занимает два машинных слова — дескриптор типа и указатель, — а сохранённые int64 дополнительно уезжают в кучу по одному на элемент. Арифметика сходится: 16 384 на сам срез плюс 8 000 на тысячу коробок — это и есть 24 384 байта и 1 001 выделение. Вот от чего дженерик действительно спасает, и спасает в разы, а не на проценты.

Обе цифры — наблюдение этой сборки и этой нагрузки, а не контракт any. Ширина интерфейсного значения зависит от архитектуры, а уедет ли значение в кучу, решает не сам факт упаковки, а анализ убегания конкретного кода и конкретной версии компилятора. Здесь значения хранятся в срезе и переживают вызов — поэтому уезжают. В блоке про одно сравнение то же преобразование в any не даёт ни одного выделения: значение не покидает функцию, и вариант через any стоит 0,9188–0,982 нс против 0,4426–0,4694 — вдвое дороже, но без единого выделения. Так что «any всегда выделяет память» — неправда, и правило «выделяет, когда переживает вызов» тоже слишком коротко: переживание — самый частый повод для убегания, но не единственный.

Сортировка: случай, где спор уже закончен

Вторая строка выглядит как сравнение дженерика со специализированной функцией и им не является. С Go 1.22 sort.Ints — это буквально одна строка:

// Note: as of Go 1.22, this function simply calls [slices.Sort].
func Ints(x []int) { slices.Sort(x) }

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

Настоящее сравнение — с двумя нижними строками, и там slices.Sort быстрее старого интерфейсного пути в 4,8 раза на этой нагрузке, а пути с замыканием — в 3,9. Из этих чисел нельзя сделать коэффициент «дженерики быстрее интерфейсов во столько-то раз», и вот почему: сравниваются не две языковые конструкции, а два разных API целиком. У slices.Sort ограничение арифметическое (cmp.Ordered), методов в нём нет, элемент известен конкретным типом — и сравнение компилируется в инструкцию. У старого пути на каждое сравнение приходится косвенный вызов, а у sort.Sort их три (Len, Less, Swap). Плюс это разные реализации алгоритма, написанные с разницей в десятилетие. Разница в 4,8 раза — сумма всего этого разом, и разложить её на слагаемые этот блок не пытается: как выглядит настоящее разложение, показано выше, в блоках 1, 6 и 7.

И побочный результат, ради которого стоит посмотреть на две нижние строки вместе: sort.Sort с IntSlice оказался медленнее sort.Slice с замыканием — 62 112–63 593 против 50 244–55 476, диапазоны не перекрываются. То есть «идиоматический» способ до дженериков был и самым медленным: на каждое сравнение приходится три косвенных вызова (Len, Less, Swap) вместо одного замыкания.

Что должно повториться, а что нет

Числа сняты на go1.24.7 linux/amd64, Intel Xeon 2,10 ГГц, GOMAXPROCS = 2. Прогон, из которого взята каждая таблица выше, лежит целиком в bench/gogenerics/runs/cost.txt; собирает его bench/gogenerics/cost.sh из cost_test.go (блоки 1–5), noinline_test.go (блок 6) и layout_test.go (блок 7). Таблицы символов — bench/gogenerics/shapes.go.

В разделах про вывод типов, тильду, ограничения и версии языка нет ни одного замера времени: их скрипты собирают код и печатают ответ компилятора — bench/gogenerics/inference.go, bench/gogenerics/tilde.go, bench/gogenerics/constraints.go, bench/gogenerics/versions.go. Эти четыре воспроизводятся слово в слово на той же версии Go — позиции в файле будут свои, а текст сообщений тот же: он часть поведения компилятора, а не измерение.

Перепроверка на go1.27.0 лежит рядом, отдельными файлами: runs/shapes-go127.txt, runs/versions-go127.txt и пара runs/toolchain-go124.txt — runs/toolchain-go127.txt. Пара снята на другой машине, чем таблицы статьи, и потому сопоставляется только сама с собой: это и есть правило, ради которого она снята парой, а не одним прогоном.

Совпадения ваших чисел с этими ждать не надо — ждать надо совпадения соотношений внутри блока. И даже соотношений не всех: как показано в разделе про вызов метода, отношение «дженерик к интерфейсу» не пережило смены экземпляра машины, хотя обе стороны остались косвенными. Ждать стоит того, что косвенный вызов дороже прямого и что встраивание в этой разнице весит больше диспетчеризации.

Главное утверждение статьи, про число тел кода, секундомером не меряется: его даёт таблица символов. Но и оно не языковая гарантия — оно воспроизводится при том же исходнике, той же версии компилятора и той же целевой конфигурации; на другой паре GOOS/GOARCH или другой сборочной конфигурации проверять надо заново тем же прогоном.

Между версиями — не обязательно, и «не обязательно» здесь не отговорка: между 1.24.7 и 1.27.0 она совпала побайтово, но это проверено, а не обещано. Группировка форм не обещана спецификацией, а статья сама показывает, где текущий компилятор расходится с собственным проектным документом; в TODO у shapify первым пунктом стоит слияние всех указательных форм в одну. Сделают — и число тел на comparable изменится, не изменив в языке ничего. Поэтому число тел кода — не константа, а результат измерения, и на новой версии его перепроверяют тем же прогоном bench/gogenerics/shapes.go.