Метрики производительности

Производительность интернационализации в JavaScript напрямую зависит от того, какие операции выполняются: форматирование чисел и дат, обработка сообщений, работа с plural rules, разбор строк, загрузка CLDR-данных, кэширование и повторное использование экземпляров. Библиотека Globalize строится поверх стандарта Unicode CLDR и предоставляет высокоуровневый API, но каждая операция имеет измеримую стоимость, которую важно понимать при проектировании высоконагруженных приложений.

Основные категории измеряемых метрик

Временные характеристики (latency)

Ключевая метрика — время выполнения операций:

  • форматирование числа (number format)
  • форматирование даты и времени (date format)
  • парсинг чисел и дат (parse)
  • разрешение сообщений (message formatting)
  • вычисление правил множественного числа (plural rules)

В Globalize эти операции могут варьироваться по стоимости в зависимости от:

  • объёма загруженных CLDR-данных
  • количества подключённых модулей
  • использования кэша
  • частоты повторного создания экземпляров Globalize

Типичный подход к измерению — performance.now():

const t0 = performance.now();
Globalize.formatNumber(1234567.89);
const t1 = performance.now();

const duration = t1 - t0;

Пропускная способность (throughput)

При массовой обработке данных важнее не единичная задержка, а количество операций в секунду:

  • number formatting ops/sec
  • date formatting ops/sec
  • message resolution ops/sec

Для нагрузки используется цикл или специализированные библиотеки бенчмаркинга:

const start = performance.now();

for (let i = 0; i < 100000; i++) {
  Globalize.formatNumber(i);
}

const end = performance.now();
const opsPerSecond = 100000 / ((end - start) / 1000);

Высокая пропускная способность достигается при:

  • предварительной инициализации CLDR
  • повторном использовании экземпляров Globalize
  • минимизации динамического выбора локали

Стоимость инициализации (initialization cost)

Инициализация Globalize включает:

  • загрузку CLDR JSON
  • инициализацию локалей
  • компиляцию правил форматирования

Метрика особенно важна в браузерах и serverless-окружениях.

Основные факторы влияния:

  • размер CLDR данных (KB/MB)
  • количество локалей
  • число подключённых модулей (number, date, message, relative-time)
  • cold start vs warm start

Инициализация часто становится самым дорогим этапом в жизненном цикле i18n.

Память (memory footprint)

Использование памяти зависит от:

  • загруженных сегментов CLDR
  • закэшированных formatter-объектов
  • количества локалей
  • хранения precompiled messages

Метрики:

  • heap size (MB)
  • retained objects
  • string duplication ratio

Особенно затратны:

  • множество локалей одновременно
  • динамическое создание форматтеров без повторного использования

Влияние CLDR на производительность

Globalize использует Unicode CLDR как источник локализационных правил. Это накладывает прямые измеримые последствия.

Размер данных

CLDR содержит:

  • числовые форматы
  • календарные системы
  • правила множественного числа
  • временные зоны
  • символы валют

Чем больше локалей загружено, тем выше:

  • время парсинга JSON
  • нагрузка на GC
  • время инициализации

Стоимость доступа к правилам

При форматировании числа:

  • выбирается локаль
  • извлекается pattern
  • применяется formatter

Если formatter не закэширован, происходит повторное построение цепочки обработки, что увеличивает latency.

Кэширование как ключевая метрика оптимизации

Globalize активно использует кэширование внутренних объектов:

  • number formatter cache
  • date formatter cache
  • message formatter cache

Метрика эффективности кэша:

  • cache hit rate (%)
  • cache miss penalty (ms)

Пример влияния:

  • холодный вызов: создание formatter + CLDR lookup
  • горячий вызов: прямое использование кешированного объекта

Разница может достигать порядков величины.

Метрики message formatting

Система сообщений (message interpolation) включает:

  • разбор шаблона
  • вычисление plural rules
  • подстановку значений

Метрики:

  • parse time (ms)
  • compile time (ms)
  • execution time (ms per message)

Компиляция сообщений обычно дороже исполнения, поэтому важна стратегия precompilation.

Предкомпиляция сообщений и её влияние

Precompiled messages позволяют перенести часть работы на этап сборки.

Метрики сравнения:

  • runtime compilation cost
  • precompiled execution cost
  • bundle size overhead

Характерный эффект:

  • снижение latency при увеличении размера bundle
  • уменьшение CPU нагрузки в runtime

Бенчмаркинг Globalize

Структура корректного теста

Для получения достоверных метрик учитываются:

  • прогрев JIT (warm-up phase)
  • разделение cold/warm runs
  • устранение влияния GC пауз
  • фиксированная локаль

Пример сравнительного теста

function benchmark(fn, iterations = 100000) {
  // warm-up
  for (let i = 0; i < 10000; i++) fn(i);

  const start = performance.now();

  for (let i = 0; i < iterations; i++) fn(i);

  const end = performance.now();
  return end - start;
}

const time = benchmark((i) => Globalize.formatNumber(i));

Метрики работы с датами

Форматирование дат включает:

  • обработку локали
  • календарные правила
  • временные зоны (если применимо)

Метрики:

  • simple date format (ms)
  • full date format (ms)
  • relative time formatting cost

Date formatting обычно дороже number formatting из-за большего числа правил.

Сравнение операций по стоимости

Условная иерархия затрат:

  1. message formatting (наиболее дорого)
  2. date formatting
  3. relative time formatting
  4. number formatting (наиболее дешёвое)

Причины:

  • сложность правил
  • количество зависимых данных CLDR
  • необходимость вычислений (plural rules, calendar logic)

Профилирование в браузере и Node.js

Используются стандартные инструменты:

  • Performance API
  • Node.js perf_hooks
  • Chrome DevTools Profiler
  • flame graphs

Измеряемые показатели:

  • CPU time
  • heap allocations
  • GC frequency
  • event loop blocking time

Метрики холодного старта

Cold start особенно критичен в:

  • serverless функциях
  • SSR (server-side rendering)
  • edge runtime

Состав метрик:

  • время загрузки CLDR
  • время инициализации Globalize
  • первый вызов formatter

Оптимизация обычно достигается:

  • предзагрузкой CLDR
  • переиспользованием экземпляров
  • минимизацией локалей

Влияние архитектуры приложения на метрики

Производительность Globalize зависит от архитектурных решений:

Singleton vs instance-per-request

  • singleton: высокий cache hit rate, низкая latency
  • per-request: высокая изоляция, но дорогая инициализация

Lazy loading локалей

  • снижает initial load time
  • увеличивает latency первого обращения к новой локали

Tree shaking

При использовании сборщиков:

  • уменьшается bundle size
  • сокращается parse time
  • снижается memory footprint

Ключевые измеряемые показатели в продакшене

Для оценки работы i18n слоя обычно фиксируются:

  • p50/p95/p99 latency форматирования
  • ops/sec для массовых операций
  • memory peak usage
  • GC pause time
  • cache hit ratio
  • cold start duration

Ошибки интерпретации метрик

Некорректные выводы часто возникают при:

  • отсутствии warm-up фазы
  • измерении без учета JIT оптимизаций
  • тестировании с разными локалями
  • смешивании cold и warm данных
  • игнорировании влияния GC

Эти факторы могут искажать результаты в несколько раз.

Нагрузочные сценарии

Типовые сценарии измерения:

  • массовое форматирование чисел в таблицах
  • генерация отчетов с датами
  • рендеринг UI с локализованными строками
  • SSR генерация страниц
  • обработка пользовательских сообщений с plural rules

Каждый сценарий имеет собственный профиль метрик, и усреднение между ними часто приводит к некорректным выводам.

Оглавление