Руководство. Средство vcperf и Windows Performance Analyzer
инструменты Аналитика сборки C++ доступны в Visual Studio 2019 и более поздних версиях. чтобы просмотреть документацию по этой версии, присвойте элементу управления выбора версии Visual Studio для этой статьи значение Visual Studio 2019 или более поздней версии. Он находится в верхней части оглавления на этой странице.
В этом руководстве вы узнаете, как использовать vcperf.exe для получения трассировки сборки C++. Вы также узнаете, как просматривать эту трассировку в Windows Performance Analyzer.
Шаг 1. Установка и настройка Windows Performance Analyzer
Windows Performance Analyzer (WPA) — это средство просмотра трассировки из Комплекта средств для развертывания и оценки Windows (ADK). Это отдельная служебная программа. Она не входит в число компонентов, которые можно установить с помощью установщика Visual Studio.
версия WPA, поддерживающая Аналитика сборки C++, доступна только в версиях Windows ADK numberd 10.1.19041.0 или более поздней версии.
Скачивание и установка WPA
Примечание. Для установки Windows Performance Analyzer требуется Windows 8 или более поздней версии.
Перейдите на страницу для скачивания Windows ADK.
Скачайте и установите последнюю версию Windows ADK.
При появлении запроса на выбор компонентов, которые нужно установить, выберите Windows Performance Toolkit. При желании можете выбрать другие компоненты, но они не нужны для установки WPA.
Настройка WPA
Для просмотра трассировок C++ Build Insights в WPA требуется специальная надстройка. Чтобы установить ее, выполните следующие действия:
Получите надстройку, скачав один из приведенных ниже компонентов. Достаточно одного из них. Выберите тот, который вам удобнее.
Скопируйте файл perf_msvcbuildinsights.dll и вставьте в каталог установки WPA.
Шаг 2. Трассировка сборки с помощью vcperf.exe
Чтобы просмотреть данные C++ Build Insights, сначала соберите их в файл трассировки, выполнив следующие действия:
Откройте x64 или Командная строка Native Tools x86 для VS в режиме администратора. (щелкните элемент меню правой кнопкой мыши и выберите пункт другие запуск от имени администратора.)
В окне командной строки введите следующую команду:
vcperf.exe /start SessionName
Вместо SessionName выберите понятное имя сеанса.
Выполните сборку проекта обычным образом. Для сборки не обязательно использовать то же окно командной строки.
В окне командной строки введите следующую команду:
vcperf.exe/Stop SessionNametraceFile. ETL
Используйте то же имя сеанса, которое выбрали для SessionName. Выберите подходящее имя для файла трассировки traceFile.etl.
Вот как выглядит типичная последовательность команд vcperf.exe в окне командной строки разработчика:
Важные примечания о vcperf.exe
Для запуска и остановки трассировки vcperf.exe требуются права администратора. Используйте окно командной строки разработчика, которое открывается с помощью команды Запуск от имени администратора.
На компьютере может выполняться только один сеанс трассировки.
Обязательно запомните имя сеанса, использованное вами для запуска трассировки. Остановить сеанс, имя которого неизвестно, может быть сложно.
Так же, как cl.exe и link.exe, служебная программа командной строки vcperf.exe включена в комплект установки MSVC. Для получения этого компонента никаких дополнительных действий не требуется.
vcperf.exe собирает сведения о всех инструментах MSVC, запущенных в системе. Поэтому вам не обязательно запускать процесс сборки с помощью той же командной строки, которая использовалась для сбора трассировки. Сборку проекта можно выполнить из другой командной строки или даже в Visual Studio.
vcperf.exe — программа с открытым кодом
Если вы хотите выполнить сборку собственной версии vcperf.exe и использовать ее, клонируйте эту программу из репозитория GitHub vcperf.
Шаг 3. Просмотр трассировки в Windows Performance Analyzer
Запустите WPA и откройте журнал только что собранной трассировки. WPA должен распознать ее как трассировку C++ Build Insights. На панели обозревателя графов слева должны отображаться следующие представления:
Если эти представления не отображаются, убедитесь, что WPA настроен правильно, как описано на шаге 1. Вы можете просмотреть данные сборок, перетащив представления в пустое окно анализа справа, как показано ниже:
Другие представления доступны на панели обозревателя графов. Перетащите их в окно «Анализ», чтобы подробнее изучить информацию, которую они содержат. Полезным является представление CPU (Sampled) (ЦП, выборка), в котором показана загрузка ЦП во время сборки.
Дополнительные сведения
Учебник. Основы использования Windows Performance Analyzer
Сведения об распространенных операциях WPA, которые могут помочь при анализе трассировок сборки.
Справочник: команды vcperf
В справочнике по командам vcperf.exe перечислены все доступные параметры команд.
Общие сведения Представления Windows Performance Analyzer
В этой статье приведены подробные сведения о представлениях C++ Build Insights в WPA.
Windows Performance Analyzer
Официальный сайт документации по WPA.
Как с помощью Windows Performance Analyzer определить скорость всех элементов автозагрузки в Windows 10
Для достижения лучшей производительности Windows очень часто рекомендуют выполнить очистку системы от устаревших файлов. В действительности эта процедура практически не влияет на скорость работы операционной системы, поскольку временные файлы обычно ею не задействуются. Если на что и нужно обращать внимание в первую очередь, так это на автозагружаемые приложения и процессы, именно они оказывают непосредственное влияние на производительность Windows и время ее загрузки.
Существует много программ, предназначенных для выявления «тормозящих» приложений, но ни одна из них не может заменить Windows Performance Analyzer или сокращенно WPA — мощный профессиональный инструмент администрирования, позволяющий определять время загрузки всех и взятых по отдельности процессов с точностью до доли миллисекунды. Единственный его существенный недостаток — сложность освоения, как никак ориентирован Performance Analyzer на системных администраторов.
Когда в окне мастера появится предложение выбрать компоненты для установки, отметьте галочкой пункт «Набор средств для оценки производительности Windows».
Установку остальных компонентов можно проигнорировать, чтобы не занимали на диске место.
Где Windows хранит отчеты о загружаемых процессах
Идентифицировать загружаемые вместе с Windows программы нетрудно. Для этого можно воспользоваться любой утилитой для анализа автозагрузки или даже штатным Диспетчером задач, кстати, умеющим показывать степень влияния той или иной программы на скорость загрузки операционной системы.
Анализируем логи в WPA
При этом в левой колонке рабочего окна утилиты у вас появятся графики. С ними мы как раз и будем работать. Нажатием на стрелку-треугольник разверните элемент Computation, в раскрывшемся списке найдите график «CPU Usage (Precise)» и перетащите его мышкой на вкладку «Analysis» — серое поле в правой части рабочего окна.
В результате в этой части окна появится три таблицы. Кликните ПКМ по любому из заголовков содержащей список запущенных в системе процессов нижней таблицы и отметьте галочкой в открывшемся контекстном меню пункт «CPU Usage (in view)».
Отмеченный столбец тут же появится в таблице.
Теперь в столбце «New Process» выделите мышкой программы, скорость загрузки которых хотите измерить, кликом ПКМ вызовите контекстное меню и выберите в нем «Filter To Sеlеction».
В списке процессов останутся только нужные.
Теперь смотрим, что из всего этого получилось. Данные в столбце «CPU Usage (in view)» представлены временем загрузки каждой программы в миллисекундах. Например, Download Master загружается 4620,797806 миллисекунд (4,62 секунды) и это много, так как средней степенью влияния считается время автозагрузки не более 1000 миллисекунд.
Теперь откройте еще одну вкладку «Analysis» и перетащите на нее график «Lifetime by Process». Точно так же выделите интересующие вас процессы и отфильтруйте их из контекстного меню. Обратите внимание на данные столбца «Start Time (s)».
Примечание: в Windows 8.1 и 10 с целью ускорения загрузки разработчики снизили влияние сторонних приложений на запуск операционной системы, тем не менее, вы можете отсрочить их загрузку, если считаете, что они тормозят запуск системы.
Руководство. Основы использования Windows Performance Analyzer
инструменты Аналитика сборки C++ доступны в Visual Studio 2019 и более поздних версиях. чтобы просмотреть документацию по этой версии, присвойте элементу управления выбора версии Visual Studio для этой статьи значение Visual Studio 2019 или более поздней версии. Он находится в верхней части оглавления на этой странице.
Эффективное использование C++ Build Insights требует некоторого опыта работы с Windows Performance Analyzer (WPA). Из этой статьи вы узнаете о стандартных операциях WPA. Дополнительные сведения об использовании WPA см. в документации по Windows Performance Analyzer.
Изменение режима представления
WPA предлагает два базовых режима для просмотра трассировок:
Вы можете переключаться между ними с помощью значков режима представления в верхней части области представления:
Выбор предустановок
Большинство представлений WPA в C++ Build Insights имеют несколько предустановок. Вы можете выбрать нужную предустановку из раскрывающегося меню в верхней части области представления:
Увеличение и уменьшение масштаба
Некоторые трассировки сборки настолько велики, что рассмотреть детали сложно. Чтобы увеличить отдельную область, щелкните диаграмму правой кнопкой мыши и выберите Zoom (Увеличить). Вы всегда можете вернуться к предыдущей настройке, нажав Undo Zoom (Отменить изменение масштаба). На этом рисунке показан пример использования выбора и команда Zoom (Увеличить) для увеличения области диаграммы:
Группирование по разным столбцам
Вы можете настроить способ отображения трассировки. Щелкните значок шестеренки в верхней части области представления и измените порядок столбцов в редакторе представлений в обозревателе сборок. Столбцы над желтой линией в этом диалоговом окне — это столбцы, по которым группируются строки данных. Обратите внимание на столбец прямо над желтой линией, так как в представлении диаграммы он отображается на цветных линейках.
На этом рисунке показан пример линейчатой диаграммы для вызова ссылок. Мы используем значок шестеренки, чтобы открыть диалоговое окно редактора представлений в обозревателе сборок. Затем мы перетащим записи столбцов Component (Компонент) и Name (Имя) и разместим их над желтой линией. Конфигурация изменится для повышения детализации и демонстрации того, что фактически произошло в компоновщике:
Почему Windows около 20 секунд упорядочивает невидимые значки Рабочего стола?
Примерно в конце января мне показали пост в Twitter, в котором пользовательница Windows с мощной машиной рассказывает о произвольных зависаниях в Проводнике. Было предложено множество ненаучных теорий. Обычно я не занимаюсь анализом проблем производительности у незнакомых людей, но этот случай показался интересным, поэтому я решил изучить его.
Фрейя отправила мне трассировку ETW того, что происходит с её машиной и я исследовал её с помощью Windows Performance Analyzer (WPA). Первым делом я заметил, что график UI Delays показывает, как и можно было догадаться, что потоку explorer.exe 7888 не удавалось проверить сообщения в течение 20,531 секунд. Он завис.
У explorer.exe есть много UI-потоков, поэтому это не значит, что повис весь процесс, однако, одно из его окон определённо зависло и вызывало зависания повсюду, а это плохо.
Если потоку не удаётся перекачивать сообщения, то это значит, что он или занят чем-то другим (потребляет ресурсы ЦП), или ожидает чего-то другого (ЦП простаивает). Изучив более детально период времени 20,531 секунд MsgCheck Delay, я проверил данные CPU Usage (Precise) (взятые из инструментария переключения контекста) и увидел, что поток 9228 был запущен в течение 99,2% времени — он потреблял много ресурсов ЦП.
Далее надо было выяснить, что происходит. Данные CPU Usage (Sampled) (получаемые от профилировщика с сэмплированием 1 кГц) сообщили мне, что поток 9228 тратит примерно 99,7% своего времени (26994 из 27074 сэмплов) в деструкторе BatchPositionChangesHelper (строка 21) и его дочерних задачах (строки 23-25). Это очень затратный деструктор.
У меня нет доступа к этому исходному коду, но я немного поизучал стеки и они намекают, что explorer.exe тратил больше 20 секунд, выполняя множество задач, связанных… с выравниванием положения значков.
Ага, именно так
Я запустил этот простой скрипт со значением file_count, равным 1000, и внезапно explorer.exe начал безумно тормозить более двадцати секунд. Всё действительно оказалось так просто.
Но почему?
Компьютеры сегодня очень быстры. Процессор Фрейи работает с частотой 4,6 ГГц, а на её Рабочем столе находится примерно 950 файлов GIF. За 20 секунд её ЦП должен выполнить 92 миллиарда тактов или по 97 миллионов тактов на каждое изображение. А это много.
Я предположил, что проблема была связана с наблюдением, которое я для себя назвал первым законом вычислений Доусона: O(n^2) — оптимальное время для плохо масштабируемых алгоритмов — достаточно быстро, чтобы попасть в продакшен, но достаточно медленно, чтобы ломать всё, после того, как он туда попал.
То есть наиболее вероятное объяснение того, почему выстраивание значков занимает так много времени, заключается в том, что код перестроения порядка значков использует O(n^2) (он же квадратичный) алгоритм, то есть при удвоении количества значков время на их выстраивание возрастает в четыре раза. При таком масштабировании производительности алгоритм, хорошо работающий с десятью элементами, может тормозить всего с тысячей элементов.
Хорошая теория, но как её доказать?
Научно!
Я начал с написания скрипта, который заполнит мой Рабочий стол заданным количеством изображений. Я многократно запускал его со всё большими количествами изображений и записал трассировку ETW, чтобы можно было замерить производительность. Также я отслеживал explorer.exe с помощью Диспетчера задач, чтобы можно было понять, когда он закончил одну задачу и готов к следующей.
Мой первый тест дал хаотичные результаты, они выглядели как нелинейный рост, но любые попытки сопоставления с линией больше походили бы на веру, чем на соответствие данным. Чтобы качественнее протестировать мою теорию, мне нужно было понять, что происходит.
Изучая трассировки, я понял, что деструктор BatchPositionChangesHelper выполнялся бОльшую часть времени (синяя область), но не всё время работы explorer (зелёная область):
Я осознал, что, помимо прочего, работа по выстраиванию прерывается работой по отображению, после чего понял причину такой вариативности.
Когда мой скрипт на Python начинал создавать изображения, процесс explorer.exe замечал это и сразу же начинал пытаться разместить значки. В процессе создания изображений он мог делать это несколько раз, что давало непредсказуемые результаты. Это была ситуация гонки, из-за которой постоянство общих затрат оказывалось нарушенным. Так как у меня не было доступа к исходному коду explorer.exe, мне нужно было придумать способ заставить его ждать завершения создания всех изображений, а потом уже выполнять выстраивание. Я реализовал это с помощью библиотеки psutil, позволившей приостановить процесс explorer.exe, пока создавались изображения. Затем, когда я возобновлял процесс, он проделывал всю работу. Код выглядит примерно так:
Сделав это, я запустил свой тестовый пакетный файл, параллельно записывая трассировку ETW. Для минимизации шума и размера трассировки я отключил стеки вызовов переключения контекста (необязательные) и выключил индексирование папки Рабочего стола. Я отслеживал загрузку ЦП процессом explorer.exe с помощью Диспетчера задач и нажимал на Enter, чтобы перейти к следующему тесту, когда загрузка падала до нуля. Так я получил очень красивый график загрузки ЦП процессом explorer.exe:
Отдельные блоки обозначают загрузку ЦП для 100, 200, 300 и так далее изображений вплоть до 1000. Если вы внимательны, то заметите, что загрузка ЦП увеличивается быстрее, чем линейно, но медленнее, чем квадратично. То есть изначальные данные позволяют предположить, что алгоритм выстраивания не-совсем-O(n^2).
Однако explorer занимается не только выстраиванием. Если некоторые из задач O(n), то есть линейны, то они ослабят влияние задач O(n^2). При увеличении n задачи O(n^2) постепенно начнут доминировать, но я не хотел, чтобы моя тестовая программа работала даже дольше 160 секунд, которых требует её выполнение.
Изолирование
Значит, следующей задачей будет изолирование времени, потраченного на деструктор BatchPositionChangesHelper. В моей тестовой трассировке оно составило 78,4% времени, потраченного в explorer.exe, и 92,3% времени, потраченного в занятом потоке, и если я смогу доказать, что оно было квадратичным, то докажу, что при увеличении n оно будет доминировать навсегда.
Для этого я посмотрел на данные CPU Usage (Sampled) и отфильтровал их, чтобы отображались сэмплы только в деструкторе BatchPositionChangesHelper и его дочерних задачах. Затем я рассмотрел десять разных областей графика и составил график количества сэмплов. Кривая настолько плавная, что выглядит подделкой, но это именно настоящие данные.
Если взглянуть на ключевые точки графика, например, где количество изображений равно 500, а потом 1000, то можно увидеть, что масштабирование производительности происходит немного хуже, чем O(n^2). То есть для выстраивания 1000 значков требуется в четыре с лишним раза больше времени, чем на выстраивание 500 значков.
Решающий удар
Обычно у меня на Рабочем столе мало значков, поэтому я практически неуязвим для этого бага. Однако я видел людей, Рабочий стол которых полностью заполнен значками. У них, вероятно, он проявляется, но в менее серьёзной форме.
Фрейя использовала свой Рабочий стол для хранения файлов GIF. Она обращалась с ним, как с папкой (чем он собственно и является), в которой можно удобно хранить изображения. Она редко пользовалась значками с Рабочего стола. Поэтому когда количество значков со временем стало избыточным, она решила снять флажок «Show desktop icons» («Отображать значки рабочего стола»), чтобы было меньше неразберихи. Значки скрылись и она могла продолжать сохранять изображения в эту папку.
Испытываемые ею зависания, при которых explorer тратил 20 с лишним секунд на выстраивание значков на Рабочем столе, тратя 92 миллиарда тактов ЦП на правильное размещение значков, происходили… тогда, когда значки были скрыты.
Это какой-то новый уровень удивительности.
Выстраивание значков в сетку изначально должно быть линейной операцией, но каким-то образом её написали квадратичной и она выполнялась вне зависимости от того, показываются значки, или нет.
Вот и всё. Если вы пишете код, который будут запускать другие, то убедитесь, что он достаточно хорошо масштабируется для обработки любого возможного множества данных, вне зависимости от его разумности. Квадратичные алгоритмы обычно проваливают эту проверку.
Ловушки
Похоже, что этот баг связан с изменением схем использования нескольких мониторов (как мне сказали, такая необходимость часто возникает у стримеров), поэтому какое-то время я проводил тесты, подключая и отключая свой внешний монитор. Это плохо подходит для эффективного тестирования, к тому же, похоже, я испортил разъём для внешнего монитора у своего личного ноутбука. Больше он не видит внешний монитор. Упс.
Да, с символами
Когда я анализировал трассировку Фрейи, я просто загрузил её в Windows Performance Analyzer (WPA) и подождал. Мне не нужно было проверять версию Windows, на которой она работала, и знать, какие патчи у неё установлены. WPA просто изучал отладочную информацию всех EXE и файлов PE и скачивал файлы символов с серверов символов Microsoft (и с серверов Chrome, потому что я это разрешил). Серверы символов — это хорошо. Если вы работаете в Windows, то включите использование серверов символов. Если вы не в Windows, то сильно вам сочувствую (жаль, что отладка и профилирование, особенно проблем на машинах других пользователей, для вас гораздо сложнее).
Сообщаем о проблеме
Не знаю, на скольких людей повлиял этот баг (те, у кого 200-300 значков, она касается достаточно слабо, а при большем количестве ситуация постепенно становится хуже), и не имею возможности его устранить. Поэтому я сообщил о нём. Я не питаю особых надежд, что его исправят. Под моим последним багом квадратичного времени в Windows ноль комментариев, несмотря на то, что я опубликовал его несколько месяцев назад.
Сырые измерения из моих тестов сохранены здесь, а сами тесты находятся на github. Этот баг чрезвычайно легко воспроизвести. Если кто-то захочет создать запись Feedback Hub, то это нужно сделать. Рекомендую при зависании Рабочего стола использовать опцию UIforETW Browse Folder — операция будет заблокирована на всё время зависания.
Уроки для разработчиков ПО
За свою карьеру я много раз участвовал в собеседованиях. Часто мне давали задание придумать алгоритм, выполняющий какую-то искусственную задачу. Очевидный алгоритм «грубого перебора» обычно оказывается квадратичным (O(n^2)) или реже экспоненциальным (O(2^n)). Чаще всего это приводит к обсуждению следующих тем:
На правах рекламы
Эпичные серверы — это виртуальные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!