Лимиты и производительность типов

Два жёстких лимита

Компилятор навязывает два потолка, дающих одно и то же сообщение об ошибке:

• Глубина инстанцирования — насколько глубоко может вкладываться одна цепочка инстанцирований типов. Не-хвостовая рекурсия упирается около 50; хвостово-рекурсивные условные типы (TS 4.5+) достигают примерно 1000.
• Количество инстанцирований — глобальный бюджет на то, сколько инстанцирований типов может запустить одно выражение. Компилятор прерывает разрастающийся тип с Type instantiation is excessively deep and possibly infinite., защищаясь от типов, которые иначе зависнут проверку навсегда.

Сообщение не различает «действительно бесконечный» и «конечный, но слишком дорогой». Оба всплывают одинаково, поэтому диагностика — это сначала проверить базовый случай, затем глубину, затем общее число инстанцирований.

Настоящий убийца: декартовы произведения объединений

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

type Pair<A, B> = A extends any ? (B extends any ? [A, B] : never) : never;
type U = "a" | "b" | "c" | "d";          // 4 члена
type Cross = Pair<U, U>;                  // 4 x 4 = 16 членов
// сцепите три таких и получите 4^3 = 64; десять объединений по 10 -> 10^10 инстанцирований

Дистрибутивное условие над 50-членным объединением, вложенное в другое дистрибутивное условие над 50-членным объединением, — это 2 500 инстанцирований для одного псевдонима типа. Сложите несколько таких — и дойдёте до миллионов. Вот почему невинно выглядящий тип может в 10 раз увеличить лаг редактора всем.

Измерять, а не гадать

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

# Куда уходит время? Итоги: parse, bind, check, счётчики инстанцирований.
tsc --noEmit --extendedDiagnostics

# Снять профиль, открываемый в chrome://tracing или анализатором.
tsc --noEmit --generateTrace ./trace
npx @typescript/analyze-trace ./trace   # ранжирует самые горячие типы и файлы

# Не дать компилятору прятать виновный тип за "..." в ошибках.
tsc --noEmit --noErrorTruncation

--extendedDiagnostics показывает Instantiations: и Check time — скачок с 200k до 5M инстанцирований после PR указывает прямо на виновника. --generateTrace плюс @typescript/analyze-trace называет конкретный псевдоним типа и место в исходнике, жгущее больше всего времени. --noErrorTruncation раскрывает полный (часто гигантский) тип, на котором компилятор давится, вместо бесполезного ....

Митигации, по убыванию рычага

1. Сократите входы. Избегайте дистрибуции по большим объединениям; отключайте обёрткой [T] там, где не нужно по-членное поведение.
2. Кэшируйте промежуточное. Дайте рекурсивному или составному типу именованный псевдоним, чтобы компилятор мемоизировал его, а не пересчитывал инлайн на каждой ссылке.
3. Предпочитайте интерфейсы большим пересечениям для горячих форм; они кэшируются по имени.
4. Избегайте глубоких цепочек условий. Уплощайте длинные лестницы A extends X ? ... : B extends Y ? ...; они множат число инстанцирований.
5. Включите --incremental (и project references), чтобы неизменные файлы переиспользовали прежний .tsbuildinfo, и перепроверялся только затронутый граф.
6. Остановитесь и валидируйте в рантайме. Ход senior: если тип стоит команде больше, чем экономит, удалите его и проверяйте инвариант в рантайме (валидатор схемы, парсер, рантайм-гард). 200-строчный тип, доказывающий, что строка — валидный маршрут, стоит меньше 5-строчной рантайм-проверки, делающей то же и ничего не стоящей редактору.

Вместе эти шесть рычагов движутся от самого дешёвого фикса (сократить входы, без структурных изменений) до самого решительного (удалить тип полностью). Если шаг 1 не помог — скорее всего, перед вами структурная проблема, которую решат только шаги 4–6.