Метапрограммирование на шаблонах C++: цена компиляции

Сборка среднего проекта на C++ уходила на CI восемь минут, а после добавления одного «удобного» заголовка с рекурсивными шаблонами стала занимать двадцать три. Никакой ошибки в коде нет — код корректен и работает. Проблема в том, что компилятор инстанцирует сотни тысяч типов, каждый из которых живёт в памяти процесса до конца трансляционной единицы. Разберём, откуда берётся эта цена и как её мерить, а не гадать.

Что именно происходит при инстанцировании

Когда вы пишете std::vector<int>, компилятор порождает отдельный тип со всеми методами. Пока это один тип — недорого. Метапрограммирование ломается на рекурсии: каждый шаг рекурсивного шаблона создаёт новый уникальный тип, и компилятор обязан хранить его в таблице символов до конца обработки файла.

Классический пример — вычисление факториала на шаблонах в стиле до C++11:

// Схематично: наивная рекурсия по типам, C++03-стиль
template<int N>
struct Factorial {
    static const long long value = N * Factorial<N - 1>::value;
};

template<>
struct Factorial<0> {
    static const long long value = 1;
};

// Factorial<20>::value порождает 21 отдельный тип:
// Factorial<20>, Factorial<19>, ..., Factorial<0>

Для одного факториала это ерунда. Но такой же паттерн в библиотеке типа обработки списков типов (type list) с глубиной в сотни элементов и десятками операций над каждым уровнем даёт квадратичный рост числа инстанцирований.

Три источника нагрузки

• Число уникальных инстанцирований. Каждый новый набор аргументов шаблона — новый тип. Компилятор их не переиспользует между разными аргументами.
• Глубина рекурсии. Влияет на стек компилятора и на длину цепочки зависимостей, которую нужно разрешить последовательно.
• Разрешение перегрузок и SFINAE. Каждая проверка enable_if или отклонённая перегрузка — работа, даже если результат отбрасывается.

Как замерить, а не угадать

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

Clang: -ftime-trace

Начиная с Clang 9 доступен флаг -ftime-trace. Он генерирует JSON рядом с объектным файлом в формате трассировки Chrome:

# Clang 14+
clang++ -std=c++20 -ftime-trace -c heavy_template.cpp

# Появится heavy_template.json
# Откройте его в about:tracing в Chrome
# или на https://ui.perfetto.dev

В трассировке вы увидите записи InstantiateClass и InstantiateFunction с именами конкретных типов и временем на каждый. Это точно показывает, какой именно шаблон съедает секунды, а не абстрактное «шаблоны медленные».

GCC: -ftime-report

У GCC есть -ftime-report — он даёт сводку по фазам компиляции, но без разбивки по конкретным типам, как у Clang. Для детального разбора по инстанцированиям trace от Clang информативнее, даже если проект вы собираете GCC.

Правило простое: сначала -ftime-trace, потом решение. Оптимизация метапрограммирования вслепую чаще всего переписывает то, что и так компилировалось за миллисекунды, и не трогает настоящий источник задержки.

Приёмы, которые реально снижают цену

Число инстанцирований — главный рычаг. Уменьшить его можно несколькими способами, и у каждого своя расплата.

1. Свёртки вместо рекурсии

C++17 добавил fold expressions. Там, где раньше нужна была рекурсивная раскрутка вариативного шаблона через вспомогательные типы, теперь работает одно выражение без порождения промежуточных типов:

// C++17: сумма всех аргументов без рекурсивных инстанцирований
template<typename... Args>
auto sum_all(Args... args) {
    return (args + ...);  // fold expression
}

Fold-выражение не создаёт по типу на каждый элемент пакета — компилятор разворачивает его напрямую. Это часто на порядок дешевле рекурсивного варианта.

2. constexpr-функции вместо вычислений на типах

Вычисления, которые исторически делали на шаблонах, в C++14 и новее почти всегда лучше писать как constexpr-функции. Компилятор считает их в обычной модели вычислений, без порождения типов:

// C++14+: считается на этапе компиляции, но без инстанцирования типов
constexpr long long factorial(int n) {
    long long result = 1;
    for (int i = 2; i <= n; ++i) result *= i;
    return result;
}

constexpr auto f20 = factorial(20);  // посчитано компилятором

Расплата: constexpr-функция не может вычислять на типах, только на значениях. Если вам нужно именно преобразование типов, этот приём не подходит.

3. Concepts вместо цепочек SFINAE

В C++20 concepts не только читаются лучше, чем нагромождение enable_if, но и разрешаются компилятором дешевле: концепт проверяется как предикат, а не через создание и отбрасывание кандидатов перегрузки. Точную разницу в вашем случае смотрите в trace — она зависит от того, сколько перегрузок отсеивалось раньше.

4. Мемоизация инстанцирований

Если один и тот же тяжёлый шаблон инстанцируется с одинаковыми аргументами в разных трансляционных единицах, каждая единица платит заново. Здесь помогает extern template — явное объявление, что инстанцирование живёт в одной единице:

// В заголовке: не инстанцировать здесь
extern template class HeavyContainer<int>;

// В одном .cpp: инстанцировать ровно один раз
template class HeavyContainer<int>;

Сравнение подходов

Когда что выбирать

Критерий один — что показал trace.

• Горит на одном типе во многих файлах — extern template. Дешевле всего внедрить, ничего переписывать не нужно.
• Горит на рекурсивной раскрутке вариативного шаблона — fold expression, если операция линейна.
• Горит на вычислениях, которые можно выразить значениями — constexpr-функция.
• Горит на разрешении перегрузок с длинными enable_if — concepts, но только если проект уже на C++20.

Где подход ломается

Оптимизация компиляции упирается в несколько граничных случаев, о которых стоит знать заранее.

• Дедупликация инстанцирований не работает между разными аргументами. HeavyContainer<int> и HeavyContainer<long> — два независимых инстанцирования, extern template нужно для каждого явно.
• constexpr не бесплатен. Слишком тяжёлые constexpr-вычисления упираются в лимит шагов интерпретатора компилятора. У Clang и GCC он настраивается флагом (-fconstexpr-steps у Clang, -fconstexpr-ops-limit у GCC), но упор в лимит — сигнал, что вычисление стоит вынести в рантайм.
• Concepts не всегда дешевле. Сложные составные концепты с большим числом требований компилятор всё равно вычисляет, и trace может показать, что выигрыша нет. Мерить обязательно.
• Precompiled headers меняют картину. Если тяжёлые заголовки уже в PCH, повторной цены за них нет, и оптимизировать их бессмысленно.

Что делать дальше

Начните с одного шага: соберите проблемную трансляционную единицу с -ftime-trace под Clang и откройте JSON в perfetto.dev. Отсортируйте записи InstantiateClass по времени — верхние три строки покажут, куда уходит бюджет сборки. Дальше применяйте приёмы точечно и после каждого пересобирайте с тем же флагом, сравнивая суммарное время фазы инстанцирования. Мерить стоит не общее время сборки (на него влияет линковка и кеш), а именно вклад инстанцирований по trace.