| 1 | # ADR 0054: Бенчмарки производительности и baseline-метрики |
| 2 | |
| 3 | **Статус:** Proposed |
| 4 | **Дата:** 2026-04-17 |
| 5 | |
| 6 | ## Связанные ADR |
| 7 | |
| 8 | | ADR | Роль | |
| 9 | |-----|------| |
| 10 | | [0021](0021-pfd-mfd-cockpit-attention-model.md) | PFD / MFD — модель внимания кокпита Cascade IDE | |
| 11 | | [0049](0049-skia-surface-rollout-over-avalonia-host.md) | Поэтапный rollout Skia-поверхностей при Avalonia-host (CIDE-wide) | |
| 12 | | [0053](0053-semantic-map-control-flow-pfd.md) | Карта намерений и поток управления на PFD (control flow) | |
| 13 | |
| 14 | --- |
| 15 | ## Контекст |
| 16 | |
| 17 | Наблюдаемая разница потребления памяти между разными инструментами (например CIDE vs Cursor) влияет на продуктовые решения и приоритеты оптимизаций. Сейчас такие сравнения делаются эпизодически и не имеют повторяемого протокола. |
| 18 | |
| 19 | Нужен единый способ измерять и обсуждать производительность без споров «померили в разных условиях». |
| 20 | |
| 21 | --- |
| 22 | |
| 23 | ## Решение |
| 24 | |
| 25 | 1. Ввести стандартный набор benchmark-сценариев для CIDE. |
| 26 | 2. Фиксировать baseline-метрики в репозитории CIDE как инженерный артефакт. |
| 27 | 3. Использовать benchmarks как gate для крупных UI/рендер/навигационных изменений. |
| 28 | |
| 29 | --- |
| 30 | |
| 31 | ## Сценарии v1 |
| 32 | |
| 33 | - `idle`: приложение запущено, решение не загружено, 60 сек стабилизации. |
| 34 | - `solution_open`: загружено типовое `.sln`, без активных build/test/debug. |
| 35 | - `editing`: открыт C#-файл среднего размера, обычная навигация/скролл. |
| 36 | - `semantic_map_file`: карта в уровне `file`. |
| 37 | - `semantic_map_controlFlow`: карта в уровне `controlFlow`. |
| 38 | - `chat_active`: открыта страница чата, активен обмен сообщениями (без долгих фоновых задач). |
| 39 | - `debug_session`: attach/launch + пауза на брейкпоинте. |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## Метрики v1 |
| 44 | |
| 45 | - Память процесса: |
| 46 | - `WorkingSet (MB)` |
| 47 | - `PrivateBytes (MB)` |
| 48 | - CPU: |
| 49 | - средняя загрузка за окно наблюдения |
| 50 | - пиковая загрузка |
| 51 | - Время отклика: |
| 52 | - время cold start до готового окна |
| 53 | - время загрузки решения до стабильного состояния |
| 54 | - Семантическая карта: |
| 55 | - время обновления карты после смены файла/каретки |
| 56 | - число узлов/рёбер в итоговом подграфе |
| 57 | |
| 58 | --- |
| 59 | |
| 60 | ## Протокол измерения |
| 61 | |
| 62 | - ОС, сборка (`Debug`/`Release`), target runtime и конфиг фиксируются в отчёте. |
| 63 | - Для каждого сценария минимум 3 прогона, отчёт в виде median + max. |
| 64 | - Сравнивать только сценарии, измеренные на одинаковой машине и в одинаковом профиле. |
| 65 | - Если используется внешний эталон (например Cursor), это указывается как `reference`, а не как жесткий SLA. |
| 66 | |
| 67 | --- |
| 68 | |
| 69 | ## Артефакты |
| 70 | |
| 71 | - В репозитории: |
| 72 | - `docs/benchmarks/README.md` — как запускать и читать результаты. |
| 73 | - `docs/benchmarks/baselines/*.json` — baseline по датам/веткам. |
| 74 | - `docs/benchmarks/reports/*.md` — человекочитаемые отчёты. |
| 75 | - Для CI (позже): smoke-бенчмарк на ограниченном наборе сценариев. |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | ## Последствия |
| 80 | |
| 81 | Плюсы: |
| 82 | - сравнения становятся повторяемыми и прозрачными; |
| 83 | - проще обосновывать оптимизации и регрессии; |
| 84 | - обсуждение «быстро/медленно» опирается на факты. |
| 85 | |
| 86 | Минусы: |
| 87 | - появляется операционная нагрузка на прогон и поддержку baseline; |
| 88 | - без дисциплины протокол быстро устаревает. |
| 89 | |
| 90 | --- |
| 91 | |
| 92 | ## Открытые вопросы |
| 93 | |
| 94 | - Нужно ли разделять baseline для `Debug` и `Release` как два равноправных контура? |
| 95 | - Какие сценарии станут обязательными для PR-gate в CI (кроме smoke)? |
| 96 | - Нужна ли автопубликация мини-дашборда изменений baseline между коммитами? |
| 97 | |