Как правильно сравнивать скорость разных версий программы в Windows

Вы хотите сравнить версии A и B программы в Windows. Хуже всего в этой ситуации — запустить каждую версию по одному разу на одной и той же машине и заявить: «Похоже, B быстрее примерно на 8%».

Эти 8% действительно могут быть разницей в коде. Но на практике классическая история бенчмаркинга в Windows звучит иначе: причиной оказывается что-то из списка — power mode, power plan, тепловой режим, фоновые обновления, индексирование поиска, антивирусное сканирование, affinity, порядок выполнения или состояние кэша. Мир довольно грязный.

В этой статье собраны способы сравнивать скорость выполнения разных версий программы в Windows так, чтобы результат был максимально близок к реальной разнице в коде. Речь в основном пойдёт о Windows 11, но большая часть материала — powercfg, start и так далее — работает точно так же и в Windows 10.

Сначала — выводы

Если сводить всё к сути, приёмов для повышения воспроизводимости результатов ровно шесть.

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

2. Фиксируйте power mode и power plan как два разных понятия Если отнестись к этому небрежно, сравнение в Windows легко превращается в сравнение политик энергосбережения самой ОС.

3. Разделяйте «холодный» первый запуск и прогретое устойчивое состояние Ситуация, когда быстрым оказывается только первый запуск (или, наоборот, медленным становится только конец серии), встречается сплошь и рядом.

4. Чередуйте запуски по схеме A→B→A→B Если сначала прогнать все запуски A, а затем все запуски B, на результат ляжет перекос от теплового режима и фоновой активности.

5. Смотрите не только на среднее, но и на медиану с разбросом Один-единственный выброс способен полностью исказить картину. Среднее хрупче, чем кажется.

6. Если разница мала, копайте до причины с помощью ETW / WPR Споры на основе субъективных ощущений обычно превращаются в бой в тумане.

Сначала определите, что вы хотите сравнить

На самом деле «сравнение скорости» — понятие, за которым скрываются два разных вида сравнения.

1. Сравнение, чтобы увидеть разницу в коде

Это сравнение, в котором вы хотите узнать, стала ли быстрее сама реализация — за счёт изменения алгоритма, структуры данных, оптимизаций компилятора, обновления рантайма и так далее.

В этом случае нужно максимально убрать шум окружения: выделенная сессия для бенчмарка, фиксированный power mode, отключённые уведомления, подавленные индексирование поиска и синхронизация, а при необходимости — вплоть до clean boot.

2. Сравнение, чтобы увидеть реальный пользовательский опыт

Здесь вы хотите узнать, насколько быстрой программа ощущается пользователями в их повседневной Windows-среде после выпуска.

В этом случае нельзя убирать весь реально существующий шум. Сравнение в «правдоподобной повседневной среде», включающей синхронизацию OneDrive, Defender, уведомления и обычные настройки питания, даёт результат, более близкий к реальности.

Если смешать эти два вида сравнения, выводы получаются перекошенными. Обычное дело — ситуации вроде «в лаборатории на 12% быстрее, а в реальности разница в пределах погрешности» или «в реальности быстрее, а по CPU-времени разницы нет».

Главные причины разброса результатов в Windows

Сначала — грубый перечень того, что вносит разброс в результаты.

Иными словами, даже «одна и та же машина с Windows» — это другой эксперимент, если условия не выровнены.

Разделяйте power mode и power plan

Этот момент довольно важен.

В Windows есть Power mode из приложения «Параметры» и традиционный Power plan — электросхема, которую видно через powercfg. Они похожи внешне, поэтому их часто путают, но небрежное обращение с ними превращает сравнение в кашу.

В приложении «Параметры» Windows Power mode выбирается в разделе Settings > System > Power & battery. Согласно документации Microsoft, для режимов Plugged in / On Battery отдельно можно переключать Best power efficiency, Balanced и Best performance. Более того, изменение Power mode влияет и на связанные с питанием настройки, и на поведение PPM (Processor Power Management). То есть одна только эта настройка может изменить политику core parking и масштабирования производительности.

Power plan, в свою очередь, — это традиционная электросхема: Balanced, High performance и так далее. Её можно посмотреть командами powercfg /list и powercfg /getactivescheme.

Сложность в том, что в Windows одновременно существуют и «оверлей» power mode, и power plan. Поэтому в результатах бенчмарка обязательно фиксируйте как минимум следующее:

• питание от сети или от батареи;
• какой Power mode установлен;
• какой Active power plan активен.

Результаты бенчмарка без этих трёх пунктов потом довольно тяжело анализировать.

Условия питания, которые нужно зафиксировать в первую очередь

1. Ноутбуки всегда сравнивайте при подключении к сети При работе от батареи легко срабатывают непредусмотренные ограничения.

2. Зафиксируйте Power mode Для целей бенчмаркинга сначала стоит попробовать Best performance.

3. Зафиксируйте активный power plan Сохраните текущее значение с помощью powercfg.

powercfg /list
powercfg /getactivescheme

1. При необходимости переключитесь на High performance

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

«High performance не отображается» — это нормально

Это ещё одно место, где легко застрять. Согласно документации Microsoft, на устройствах с поддержкой Modern Standby разрешён только план Balanced или производные от него планы. Поэтому вместо вопроса «High performance не найден, он что, сломался?» стоит учитывать, что это может быть особенностью конструкции конкретной модели.

Кроме того, Microsoft советует: если Power mode изменить не удаётся, возможно, выбран пользовательский (custom) power plan, поэтому для начала стоит попробовать выбрать Balanced. Если элементы управления Power mode не реагируют, это первое, что стоит заподозрить.

Устраняем фоновый шум

Windows — трудолюбивая система. Даже когда вы хотите тихо провести бенчмарк, она всё равно что-то делает в фоне.

Сначала перезагрузитесь и подождите, пока всё уляжется

После изменения настроек перезагрузитесь один раз и не запускайте бенчмарк сразу после входа в систему — подождите несколько минут. Сразу после запуска обновления, индексирование, синхронизация, Defender и разные резидентные процессы ещё вовсю активны.

Для серьёзного сравнения используйте clean boot

Microsoft описывает процедуру, позволяющую с помощью clean boot свести конфигурацию запуска к минимуму: остановить в msconfig все службы, не относящиеся к Microsoft, и отключить автозагрузку приложений (Startup apps) в диспетчере задач.

Это мощный способ снизить шум. Однако он отдаляет систему от повседневного окружения, поэтому подходит для «лабораторного сравнения ради разницы в коде».

Отключаем уведомления

Баннеры уведомлений Windows кажутся мелочью, но на деле неожиданно мешают. Дело не только в визуальном отвлечении — они способны менять тайминг выполнения, фокус и фоновую активность приложений.

Включите Do not disturb вручную либо, как минимум, отключите уведомления на время бенчмарка.

Подавляем индексирование поиска и синхронизацию

Если объект бенчмарка читает много файлов, генерирует много артефактов или многократно пересобирает дерево исходников, индексирование поиска и облачная синхронизация незаметно, но ощутимо бьют по результатам.

• Исключите каталог бенчмарка из области индексирования поиска
• Приостановите синхронизацию OneDrive / Dropbox / Google Drive и подобных сервисов
• Закройте браузер, Teams, Discord, Slack

Ничего эффектного здесь нет, но когда это влияет, влияет заметно.

Сравнение без выравнивания теплового режима — это, по сути, сравнение теплового режима

CPU и GPU в холодном и в прогретом состоянии — это практически разные устройства. Особенно заметно это на ноутбуках, тонких мини-ПК и компактных настольных системах.

Правила, которых стоит придерживаться

• Поддерживайте максимально одинаковую температуру в помещении
• Фиксируйте способ размещения ноутбука
• Фиксируйте конфигурацию адаптера питания, док-станции и внешних дисплеев
• Не выполняйте тяжёлую работу непосредственно перед бенчмарком
• Измеряйте первый запуск и устойчивое состояние отдельно

Чередуйте порядок выполнения

Избегайте схемы «сначала 10 запусков A, затем 10 запусков B» — на результат ляжет перекос от теплового режима, кэша и фоновой активности.

Рекомендуются такие варианты:

• A B A B A B ...
• A B B A A B B A ...
• Заранее сгенерировать случайный порядок и выполнять запуски в нём

От того, что вы измеряете, зависит смысл слова «быстро»

Если сжать понятие «быстро» до одного числа, обычно получается авария. Вот три главных показателя, на которые стоит смотреть в Windows.

1. Wall-clock time (реальное время)

Это время, которое ждёт пользователь. Оно ближе всего к сквозному (end-to-end) восприятию, поэтому именно на него стоит смотреть в первую очередь.

В Windows для получения времени с высоким разрешением можно использовать QueryPerformanceCounter (QPC). В managed-коде базовый вариант — семейство классов Stopwatch. Смотреть на миллисекунды через DateTime.Now — это, откровенно говоря, немного беспечно.

2. CPU time (пользовательское время + время ядра)

Это время, которое процесс реально использовал CPU; его можно получить через GetProcessTimes.

Этот показатель удобен для оценки вычислительной эффективности. Например, если wall-clock время сократилось, а CPU time не изменилось, вероятно, сыграли роль кэш, ввод-вывод, время ожидания или планирование.

3. Cycle count (число циклов CPU)

С помощью QueryProcessCycleTime можно получить общее число циклов CPU для всего процесса.

Это тоже показатель объёма работы CPU, но он раскрывает иную сторону картины, отличную от wall-clock. Особенно полезен, когда нужно понять: «время ожидания то же самое, но стала ли легче вычислительная часть?»

priority, affinity и NUMA — крайние средства

Эти настройки действительно способны повлиять на результат. Но если трогать их с самого начала только потому, что они работают, легко создать совершенно другое явление.

Сначала измеряйте в обычном режиме

Если разница проявляется уже в состоянии по умолчанию, эта разница сама по себе представляет ценность. А если сразу добавить /high или /affinity, вы привнесёте «условия, которые не встречаются в реальной Windows».

Если всё же используете их — чётко определите цель

• /high: хотите меньше страдать от помех со стороны других процессов
• /affinity: хотите зафиксировать размещение по CPU для сравнения
• NUMA-управление: хотите выровнять даже локальность памяти на крупных машинах

Команда start в Windows позволяет запускать процесс с указанием класса приоритета и маски affinity.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

Но откажитесь от /realtime

/realtime технически доступен, но использовать его не стоит. Он скорее не устраняет шум, а создаёт новые проблемы.

Рекомендуемая процедура измерений

С учётом всего сказанного выше — практичная процедура, удобная для реального применения.

Процедура сравнения, ориентированная на лабораторные условия

1. Зафиксируйте объекты сравнения
   • commit hash / номер сборки
   • версия компилятора / рантайма
   • Debug / Release
   • наличие логирования, assert, трассировки
2. Зафиксируйте условия машины
   • сборка Windows
   • версия BIOS / UEFI
   • версия драйверов
   • подключение к сети переменного тока
   • температура в помещении, способ размещения
3. Зафиксируйте условия питания
   • определите Power mode
   • зафиксируйте активный power plan
4. Перезагрузитесь
5. Подождите несколько минут перед бенчмарком
6. При необходимости выполните clean boot
7. Добавьте прогрев (warm-up)
8. Чередуйте запуски A / B
9. Обеспечьте достаточное число повторов
10. Сохраняйте медиану, минимум, максимум, p95
11. Сохраняйте необработанные (raw) данные
12. При небольшой разнице снимайте трассировку ETW / WPR

Что полезно фиксировать заранее

В CSV или JSON бенчмарка полезно сохранять как минимум следующее.

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

Если есть возможность, дополнительно пригодятся и такие поля.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

В бенчмаркинге зачастую важнее не сам факт измерения, а возможность интерпретировать результат позже.

Смотрите не только на среднее, но и на медиану с распределением

Среднее значение удобно, но в бенчмарках на Windows оно легко искажается. Достаточно, чтобы один раз сработал Defender, всплыло уведомление или другой процесс нагрузил SSD — и среднее уже уехало в сторону.

Рекомендуется такая комбинация показателей:

• Медиана: смотрите на неё в первую очередь
• p95 / p99: проверяйте, не ухудшился ли «хвост» распределения
• min / max: смотрите, насколько сильны отклонения
• Диаграммы размаха (box plot) и точечные диаграммы: полезны, когда разница мала

Как интерпретировать разницу, если она есть

Интерпретировать результаты проще всего, глядя на их сочетания.

Быстрее только wall-clock

Возможно, улучшились I/O, время ожидания, кэш или планирование.

Снизились и CPU time, и число циклов

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

Медленно или быстро только на первом запуске

Это разница между «холодным» и «тёплым» состоянием. Стоит подозревать запуск, инициализацию, формирование кэша, JIT-компиляцию.

Замедление с каждым следующим запуском

Стоит подозревать тепловой режим, троттлинг, нехватку памяти, фоновую активность.

Докапываемся до причины «почему быстрее» с помощью ETW / WPR

Когда разница мала или причину не удаётся прочитать по обычным метрикам, классический путь — перейти к инструментам Windows на базе ETW (Event Tracing for Windows).

Windows Performance Recorder (WPR) от Microsoft — это инструмент записи на основе ETW, входящий в состав Windows ADK. Он позволяет разом собрать данные по CPU, I/O, переключениям контекста, page fault и другим событиям.

Минимальный вариант выглядит так.

wpr -start CPU -filemode

REM Здесь выполняется бенчмарк

wpr -stop trace.etl

На этом этапе вы можете говорить не «B быстрее на 3%», а с указанием причины: «У B меньше времени ожидания на блокировках, и ready time снизилось», «У A больше операций открытия файлов, из-за чего медленнее холодный старт».

Итоги

При сравнении разных версий программы в Windows по-настоящему помогают не эффектные трюки. Важна неброская, но реально влияющая на воспроизводимость дисциплина:

• Фиксируйте и записывайте AC / Power mode / power plan
• Разделяйте cold и warm
• Чередуйте запуски A / B
• Смотрите на медиану и распределение
• При необходимости используйте clean boot
• Если разница мала, докапывайтесь до причины с помощью ETW / WPR

И самое главное — вместе с результатами всегда записывайте, что именно вы зафиксировали, а что нет. Бенчмарк — это одновременно и сравнение скорости, и протокол условий эксперимента.

Отчёт об ускорении без описания условий занятен примерно как гадание, которое иногда сбывается, но с точки зрения воспроизводимости на него мало можно положиться. И наоборот: если условия аккуратно зафиксированы, результат представляет реальную ценность, даже если разница невелика.

Справочные материалы

• Microsoft Support: Change the power mode for your Windows PC
• Microsoft Learn: Power Policy Settings
• Microsoft Learn: Customize the Windows performance power slider
• Microsoft Learn: Powercfg command-line options
• Microsoft Support: How to perform a clean boot in Windows
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Microsoft Support: Search indexing in Windows
• Microsoft Learn: Configure custom exclusions for Microsoft Defender Antivirus
• Microsoft Support: Device Security in the Windows Security App
• Microsoft Learn: QueryPerformanceCounter function
• Microsoft Learn: Acquiring high-resolution time stamps
• Microsoft Learn: GetProcessTimes function
• Microsoft Learn: QueryProcessCycleTime function
• Microsoft Learn: start command
• Microsoft Learn: SetPriorityClass function
• Microsoft Learn: SetProcessAffinityMask function
• Microsoft Learn: Processor Groups
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: WPR Command-Line Options

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

Какие основные причины разброса результатов бенчмарков в Windows?

Существует множество факторов на разных уровнях: power mode и power plan, тепловой режим, фоновые обновления, индексирование поиска, антивирусное сканирование, приоритет и affinity, порядок выполнения, состояние кэша. Даже на одной и той же Windows-машине, если эти условия не выровнены, результат — это фактически другой эксперимент. Особенно на ноутбуках поведение сильно меняется в зависимости от того, работает ли устройство от сети или от батареи, поэтому важно всегда сравнивать при подключении к сети переменного тока и фиксировать условия измерения.

В чём разница между power mode и power plan?

Power mode — это переключатель Best power efficiency / Balanced / Best performance в приложении «Параметры», в разделе Power & battery; он влияет на связанные с питанием настройки и поведение PPM (Processor Power Management). Power plan — это традиционная электросхема, которую можно посмотреть через powercfg, например Balanced или High performance. Поскольку в Windows существуют оба понятия, в результатах бенчмарка необходимо как минимум фиксировать три вещи: питание от сети или от батареи, текущий power mode и активный power plan.

Означает ли отсутствие плана High performance, что устройство неисправно?

Скорее всего, это не поломка. Согласно документации Microsoft, на устройствах с поддержкой Modern Standby разрешён только план Balanced или производные от него планы. То есть отсутствие High performance на конкретной модели может быть особенностью её конструкции — и это совершенно нормально. Кроме того, если элементы управления Power mode недоступны для изменения, вероятно, выбран пользовательский (custom) power plan, поэтому проще всего сначала попробовать выбрать Balanced.

В каком порядке следует запускать сравнение скорости версий A и B?

Не стоит сначала полностью прогонять все запуски версии A, а затем версии B — в этом случае перекос от теплового режима, кэша и фоновой активности ляжет только на одну из версий. Лучше чередовать запуски по схеме A B A B или использовать заранее сгенерированный случайный порядок. Также стоит отдельно измерять «холодный» первый запуск и установившееся состояние после прогрева, а смотреть не только на среднее значение, но и на медиану, p95, минимум и максимум — это защитит результат от искажения выбросами.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.