Перейти к содержанию

ADR 0054: Бенчмарки производительности и baseline-метрики

Статус: Proposed
Дата: 2026-04-17

Связанные ADR

ADR Роль
0021 PFD / MFD — модель внимания кокпита Cascade IDE
0049 Поэтапный rollout Skia-поверхностей при Avalonia-host (CIDE-wide)
0053 Карта намерений и поток управления на PFD (control flow)

Контекст

Наблюдаемая разница потребления памяти между разными инструментами (например CIDE vs Cursor) влияет на продуктовые решения и приоритеты оптимизаций. Сейчас такие сравнения делаются эпизодически и не имеют повторяемого протокола.

Нужен единый способ измерять и обсуждать производительность без споров «померили в разных условиях».

Решение

  1. Ввести стандартный набор benchmark-сценариев для CIDE.
  2. Фиксировать baseline-метрики в репозитории CIDE как инженерный артефакт.
  3. Использовать benchmarks как gate для крупных UI/рендер/навигационных изменений.

Сценарии v1

  • idle: приложение запущено, решение не загружено, 60 сек стабилизации.
  • solution_open: загружено типовое .sln, без активных build/test/debug.
  • editing: открыт C#-файл среднего размера, обычная навигация/скролл.
  • semantic_map_file: карта в уровне file.
  • semantic_map_controlFlow: карта в уровне controlFlow.
  • chat_active: открыта страница чата, активен обмен сообщениями (без долгих фоновых задач).
  • debug_session: attach/launch + пауза на брейкпоинте.

Метрики v1

  • Память процесса:
  • WorkingSet (MB)
  • PrivateBytes (MB)
  • CPU:
  • средняя загрузка за окно наблюдения
  • пиковая загрузка
  • Время отклика:
  • время cold start до готового окна
  • время загрузки решения до стабильного состояния
  • Семантическая карта:
  • время обновления карты после смены файла/каретки
  • число узлов/рёбер в итоговом подграфе

Протокол измерения

  • ОС, сборка (Debug/Release), target runtime и конфиг фиксируются в отчёте.
  • Для каждого сценария минимум 3 прогона, отчёт в виде median + max.
  • Сравнивать только сценарии, измеренные на одинаковой машине и в одинаковом профиле.
  • Если используется внешний эталон (например Cursor), это указывается как reference, а не как жесткий SLA.

Артефакты

  • В репозитории:
  • docs/benchmarks/README.md — как запускать и читать результаты.
  • docs/benchmarks/baselines/*.json — baseline по датам/веткам.
  • docs/benchmarks/reports/*.md — человекочитаемые отчёты.
  • Для CI (позже): smoke-бенчмарк на ограниченном наборе сценариев.

Последствия

Плюсы: - сравнения становятся повторяемыми и прозрачными; - проще обосновывать оптимизации и регрессии; - обсуждение «быстро/медленно» опирается на факты.

Минусы: - появляется операционная нагрузка на прогон и поддержку baseline; - без дисциплины протокол быстро устаревает.

Открытые вопросы

  • Нужно ли разделять baseline для Debug и Release как два равноправных контура?
  • Какие сценарии станут обязательными для PR-gate в CI (кроме smoke)?
  • Нужна ли автопубликация мини-дашборда изменений baseline между коммитами?