Бенчмарки и методология измерений

## Методология измерений производительности SWC Измерение производительности SWC требует строгого разделения этапов компиляции, типизации и трансформации, поскольку итоговые показатели сильно зависят от характера входного кода, конфигурации пайплайна и условий выполнения. SWC представляет собой высокопроизводительный компилятор JavaScript и TypeScript, реализованный на Rust, поэтому корректная интерпретация бенчмарков должна учитывать не только JavaScript-окружение, но и нативные оптимизации, работу с памятью и особенности многопоточности. --- ## Базовые принципы корректного бенчмаркинга ### Изоляция измеряемой операции Любой бенчмарк SWC должен строго ограничивать область измерения: * парсинг (parsing AST) * трансформация (transforms: JSX, TypeScript, ESNext) * генерация кода (codegen) * минификация (minification) * полный pipeline (end-to-end compilation) Смешивание этапов без разделения приводит к искажению метрик, поскольку узкие места могут находиться в разных слоях. --- ### Разделение холодного и тёплого запуска SWC использует нативные структуры данных и может быть чувствителен к инициализации: **Cold start:** * загрузка бинарных модулей * инициализация кешей * прогрев JIT для JS-обвязки (если используется Node API) * аллокации памяти **Warm start:** * повторные вызовы компиляции * использование уже загруженных модулей * стабильное состояние кэша Методологически важно фиксировать оба режима отдельно, поскольку различие может достигать кратных коэффициентов. --- ### Контроль влияния V8 и Node.js При использовании SWC через Node.js API добавляется слой JavaScript-обвязки: * влияние V8 garbage collector * JIT-оптимизации функций обёртки * скрытые классы и инлайнинг Для чистоты измерений рекомендуется: * фиксировать версию Node.js * отключать фоновые задачи * использовать флаги стабильного режима исполнения * прогревать процесс перед серией измерений --- ## Метрики производительности ### Throughput (операций в секунду) Один из ключевых показателей SWC: * количество файлов, обрабатываемых в секунду * количество строк кода в секунду * количество AST-узлов в секунду Throughput особенно важен для монорепозиториев и CI-пайплайнов. --- ### Latency (задержка одного преобразования) Измеряет время обработки одного файла: * среднее значение (mean) * медиана (p50) * 95-й процентиль (p95) * 99-й процентиль (p99) Использование процентилей критично, так как распределение времени компиляции часто имеет длинный хвост из-за больших файлов. --- ### Memory footprint SWC активно использует аллокации Rust-памяти: * пик потребления памяти (RSS) * стабильное потребление при batch-компиляции * фрагментация heap * влияние параллельной обработки Особое внимание уделяется сценарию многопоточной компиляции, где память масштабируется нелинейно. --- ## Типы бенчмарков SWC ### Синтетические бенчмарки Используются для изолированной оценки: * генерация искусственного AST * шаблонные JS/TS файлы * фиксированная глубина вложенности * контроль количества импортов и экспортов Преимущество — повторяемость. Недостаток — слабая корреляция с реальными проектами. --- ### Реальные кодовые базы Используются крупные проекты: * React-подобные UI-библиотеки * серверные monorepo * фреймворки с большим количеством модулей Метрики в таких условиях отражают реальную производительность, но обладают высокой дисперсией. --- ### Дифференциальные бенчмарки Сравнение SWC с альтернативами: * Babel * esbuild * TypeScript compiler (tsc) Фокус измерений: * относительное время выполнения * эквивалентность выходного AST * корректность трансформаций --- ## Факторы, влияющие на результаты ### JIT-эффекты и прогрев Даже при использовании нативного SWC через Node API: * первые вызовы медленнее из-за загрузки FFI * последующие вызовы ускоряются за счёт кеширования * возможна деградация при перегреве CPU --- ### Параллелизм SWC поддерживает многопоточность через Rayon: * линейное ускорение ограничено количеством ядер * накладные расходы на синхронизацию AST * эффект конкуренции за память Важно фиксировать: * число потоков * стратегию разбиения задач (chunking) --- ### Размер входного кода Производительность SWC нелинейна: * маленькие файлы → доминирует overhead вызова * средние файлы → оптимальный баланс * большие файлы → рост нагрузки на GC и codegen --- ### Файловая система и IO При end-to-end измерениях значительную роль играет: * скорость чтения диска * кеш ОС * влияние SSD vs HDD * количество файлов в директории Корректные бенчмарки должны минимизировать IO или отделять его от вычислений. --- ## Методология проведения измерений ### Подготовка окружения Фиксация условий: * версия SWC * версия Node.js (если используется) * версия операционной системы * архитектура CPU (x64, ARM64) * отключение фоновых процессов --- ### Прогрев (warm-up phase) Перед фиксацией результатов выполняется серия прогонов: * 10–50 итераций компиляции * стабилизация JIT (если применимо) * заполнение кешей загрузчика модулей --- ### Основной цикл измерений Используется многократное повторение: * минимум 30–100 прогонов * случайная перестановка входных файлов * контроль дрейфа времени выполнения --- ### Статистическая обработка Применяются методы: * медиана вместо среднего при наличии выбросов * trimming (обрезка 5% экстремальных значений) * bootstrap для оценки доверительных интервалов * анализ дисперсии между прогонами --- ## Типичные ошибки в бенчмарках SWC ### Игнорирование warm-up Приводит к завышению времени первого запуска и искажению результатов сравнения. --- ### Использование слишком малого набора данных Малые датасеты: * не отражают реальную нагрузку * усиливают влияние overhead вызова функции * дают нестабильные результаты --- ### Неправильное сравнение инструментов Некорректно сравнивать SWC с Babel без: * одинаковых конфигураций трансформаций * идентичного набора плагинов * одинакового target environment --- ### Отсутствие контроля памяти Игнорирование memory pressure приводит к: * скрытым паузам GC * деградации производительности в batch-режиме * ложным выводам о линейной скорости --- ## Инструменты профилирования ### CPU profiling Используются: * flamegraph * perf (Linux) * встроенные профайлеры Node.js Позволяет выявить: * горячие функции Rust-ядра * узкие места в codegen * overhead JS-обвязки --- ### Memory profiling Методы: * heap snapshots * RSS tracking * аллокационные профили Rust Особенно важно для выявления: * утечек при долгих batch-компиляциях * избыточных копирований AST --- ### Trace-based analysis Позволяет анализировать: * временные интервалы этапов компиляции * параллельные задачи * блокировки потоков --- ## Интерпретация результатов SWC часто демонстрирует: * высокую пропускную способность на больших кодовых базах * значительное преимущество над интерпретируемыми пайплайнами * зависимость производительности от степени параллелизма Однако корректная интерпретация требует учитывать: * разницу между latency и throughput * влияние warm-up эффектов * вариативность входных данных * архитектурные ограничения CPU --- ## Репрезентативность и воспроизводимость Ключевое требование к бенчмаркам SWC — воспроизводимость: * фиксированные версии зависимостей * неизменяемые входные датасеты * документированные параметры запуска * публичные скрипты измерений Только при соблюдении этих условий результаты могут использоваться для сравнения версий SWC или альтернативных инструментов трансформации JavaScript.