Visual studio profiler как пользоваться
Вам когда-нибудь нужно было отлаживать или профилировать исполняемый файл (файл .exe), для которого у вас нет исходного кода или вы не можете его собрать? Тогда наименее известный тип проекта Visual Studio, проект EXE, для вас!
В Visual Studio вы можете открыть любой EXE-файл как «проект». Просто перейдите в Файл -> Открыть -> Проект/Решение и перейдите к файлу .exe . Как если бы это был файл .sln . Visual Studio откроет этот EXE-файл как проект. Эта функция существует уже давно. Она работает на всех поддерживаемых в настоящее время версиях Visual Studio, и документация по ней находится на странице Отладка приложения, которое не является частью решения Visual Studio.
Отладка
Как и в обычном проекте, вы можете начать отладку с помощью F5, которая запустит EXE и подключит отладчик. Если вы хотите отладить запуск, вы можете запустить с помощью F11, который запустит EXE и остановится на первой строке пользовательского кода. Оба эти параметра доступны в контекстном меню для проекта EXE в окне Solution Explorer, как показано ниже:
Для отладки понадобятся символы, файлы PDB, для EXE и любых DLL, которые нужно отладить. Visual Studio будет следовать тому же процессу и попытается получить символы также, как и при отладке обычного проекта. Поскольку маловероятно, что файлы PDB были распространены вместе с EXE-файлом, возможно, вы захотите найти их в сборке или, что еще лучше, на сервере символов. Дополнительную информацию и рекомендации по использованию символов можно найти в этом блоге.
Для эффективной отладки вам также понадобится исходный код, который использовался для сборки EXE, или даже для нескольких файлов, которые вас интересуют. Вам нужно найти эти файлы и открыть их в Visual Studio. Если исходный код не совпадает с исходным кодом, который был собран, EXE Visual Studio предупредит вас, когда вы попытаетесь вставить точку останова, и точка останова не будет привязана. Это поведение может быть изменено в окне Settings peek window. В окне просмотра параметров щелкните текст ссылки Must match source, а затем установите флажок, чтобы разрешить несоответствующий источник, как показано ниже. Конечно, с несоответствующим источником вы никогда не знаете, что произойдет, так что используйте это только на свой страх и риск.
Если EXE был собран с SourceLink, то информация об источнике будет включена в PDB, и Visual Studio попытается загрузить источник автоматически. Это действительно хорошая причина использовать SourceLink с вашими проектами. Даже если у вас есть локальный набор, у вас может не быть той версии, которая использовалась для сборки двоичного файла. SourceLink — ваш надежный способ убедиться, что правильный источник связан с правильным двоичным файлом.
Если вы не можете получить исходный код, у вас еще есть несколько вариантов:
Профилирование
Заключение
Вот и все. Краткий обзор того, как вы можете использовать Visual Studio для отладки и профилирования приложений, которые вы не создаете и которые могут даже не иметь исходного кода. В следующий раз, когда вам понадобится отладить или профилировать EXE-файл, не забудьте, что вы можете открыть его как решение в Visual Studio!
В данном обзоре приводится информация об основах профилирования. Разработчики, у которых нет опыта анализа производительности, узнают, как средства профилирования Visual Studio позволяют быстро повысить продуктивность их работы и производительность их кода. Разработчики, обладающие опытом профилирования, получат представление об особенностях функций и процессов средств профилирования.
Средства профилирования Visual Studio помогают идентифицировать проблемы производительности на уровне исходного кода, а также сравнить производительность различных возможных решений. Мастера средств профилирования и параметры по умолчанию позволяют сразу же получить представление о многих проблемах производительности. Функциональные возможности и настройки средств профилирования обеспечивают полное управление процессом профилирования. В процессе управления используются средства точной настройки разделов кода, сбор информации о времени выполнения на уровне блоков, а также включение дополнительных данных об использовании процессора и производительности системы в данные отчета.
Процесс использования средств профилирования состоит из следующих шагов.
Настройка сеанса анализа производительности путем указания метода сбора и данных, которые требуется собирать.
Сбор данных профилирования путем запуска приложения в рамках сеанса анализа производительности.
Анализ данных для выявления проблем с производительностью.
Изменение кода в интегрированной среде разработки (IDE) Visual Studio для повышения производительности кода приложения
Собрать данных профилирования для измененного кода и сравнение данных профилирования исходных и измененных данных.
Создание отчета, в котором документируется повышение производительности.
Чтобы работать с информацией, предоставляемой средствами профилирования, необходимо располагать символьной информацией для профилируемых двоичных файлов, а также для двоичных файлов операционной системы Windows.
Настройка сеанса анализа производительности
Чтобы настроить сеанс профилирования, выберите метод профилирования, который будет использоваться, и данные, которые требуется собирать. Базовые настройки можно задать при помощи диалогового окна Мастер производительности средств профилирования, дополнительные настройки задаются с помощью страниц свойств сеанса анализа производительности.
Поддерживаются следующие методы сбора данных: выборка, трассировка и выделение памяти.
В качестве значений данных могут использоваться счетчики производительности, связанные со временем, загрузкой процессора и операционной системой, а также события приложений, например сбои страниц и переходы в режим ядра.
Сеанс анализа производительности может настраиваться как этап проекта решения в рамках проекта Visual Studio, кроме того, интегрированная среда разработки Visual Studio позволяет выполнять профилирование произвольных двоичных файлов. Параметры сеанса могут указываться на страницах свойств сеанса анализа производительности или задаваться с помощью мастера профилирования.
Сбор данных профилирования
Сбор данных профилирования начинается в окне Обозреватель производительности. Чтобы ограничить объем собираемых данных, можно приостанавливать и продолжать профилирование. Кроме того, можно присоединиться к уже выполняющемуся процессу.
Как только приложение запускается, в интерфейсе IDE Visual Studio появляется окно Управление сбором данных. В окне Управление сбором данных можно выполнять профилирование отдельных составляющих приложения путем приостановки и продолжения сбора данных. Кроме того, окно Управление сбором данных позволяет вставлять метки в собираемые данные. Метки представляют собой определяемые пользователем точки данных, которые отображаются в представления профилирования и могут использоваться для фильтрации данных профилирования.
Когда работа целевого приложения завершается, средства профилирования формируют файл данных профилирования (*.vsp), а в интерфейсе Visual Studio IDE отображается представление сводного отчета.
Анализ данных и идентификация проблем с производительностью
По окончании профилирования выполняется анализ данных и сводная информация отображается в окнах представления Отчет о производительности средств профилирования. Сбор данных профилирования выполняется для стека вызовов и отдельных функций целевого приложения. В представлениях отчетов отображается анализ производительности для диапазонов данных процессов, потоков, модулей, функций и строк исходного кода приложения. В качестве данных профилирования для функции регистрируются следующие показатели.
Общее время, затраченное на выполнение функции и дочерних функций, которые были вызваны из рассматриваемой функции (инклюзивное время).
Время, затраченное только на выполнение кода самой функции (эксклюзивное время).
Более двенадцати различных представлений позволяют выполнять анализ данных профилирования наиболее эффективным образом. Возможности настройки представлений пользователем позволяют выполнять фильтрацию и сортировку данных, чтобы облегчить поиск функций, которые могут вызывать проблемы с производительностью. Функция фильтрации критического пути позволяет моментально выделить большинство активных путей в представлениях "Дерево вызовов" и "Модуль".
Изменение кода приложения
После идентификации одной или нескольких проблем с производительностью можно изменить код приложения с помощью интерфейса IDE Visual Studio и собрать данные профилирования для измененного кода приложения.
Повторный сбор данных профилирования и сравнение данных, собранных в процессе двух запусков профилирования
В представлении "Отчет о сравнении" средств профилирования отображаются различия производительности между двумя выбранными файлами данных профилирования на уровне модулей, функций или строк исходного кода. Можно указать значения данных профилирования, с которыми требуется выполнить сравнение; кроме того, можно переключаться между представлением сравнения и представлениями отдельных файлов.
Создание отчета о результатах
Сегодня мы будем замерять производительность нашего приложения с помощью Visual Studio Profiling Tool.
Visual Studio Profiling Tool позволяет разработчикам измерять, оценивать производительность приложения и кода. Эти инструменты полностью встроены в IDE, чтобы предоставить разработчику беспрерывный контроль.
В этом руководстве мы по шагам профилируем приложение PeopleTrax используя Sampling и Instrumentation методы профилирования, чтобы выявить проблемы в производительности приложения.
Подготовка
Методы профилирования
Чуть-чуть отступим от главной темы статьи и рассмотрим возможные методы профилирования. Эту главу можно пропустить, используемые методы профилирования будут кратко описаны перед использованием.
Sampling
Sampling — собирает статистические данные о работе приложения (во время профилирования). Этот метод легковесный и поэтому, в результате его работы очень маленькая погрешность в полученных данных.
Каждый определенный интервал времени собирается информация о стеке вызовов (call stack). На основе этих данные производится подсчет производительности. Используется для первоначального профилирования и для определения проблем связанных с использование процессора.
Instrumentation
Instrumentation — собирает детализированную информацию о времени работы каждой вызванной функции. Используется для замера производительности операций ввода/вывода.
Метод внедряет свой код в двоичный файл, который фиксирует информацию о синхронизации (времени) для каждой функции в файл, и для каждой функции которые вызываются в этой.
- Elapsed Inclusive — общее время, затраченное на выполнение функции
- Application Inclusive — время, затраченное на выполнение функции, за исключением времени обращений к операционной системе.
- Elapsed Exclusive — время, затраченное на выполнение кода в теле. Время, которое тратят функции, вызванные целевой функцией.
- Application Exclusive — время, затраченное на выполнение кода в теле. Исключается время, которое тратится выполнения вызовов операционной системы и время, затраченное на выполнение функций, вызванные целевой функцией.
Concurrency
Concurrency – собирает информацию о многопоточных приложения (как отлаживать многопоточные приложения см. «Руководство по отладке многопоточных приложений в Visual Studio 2010»). Метод собирает подробную информацию о стеке вызовов, каждый раз, когда конкурирующие потоки вынуждены ждать доступа к ресурсу.
Tier Interaction
На этом рассмотрение методов профилирование закончим и продолжим учиться профилировать приложения.
Профилирование Sampling методом
Sampling это метод профилирования, который периодически опрашивает рассматриваемый процесс, чтобы определить активную функцию. В результате показывает количество раз, когда функция была в начале call stack во время тестирования.
Профилирование
Открываем тестовый проект PeopleTrax. Устанавливаем конфигурацию в Release (в Debug версию встраивается дополнительная информация для отладки приложения, и она плохо скажется на точности результатов профилирования).
В меню Analyze нажимаем на Launch Performance Wizard.
На этом шаге нужно выбрать метод профилирования. Выбираем CPU Sampling (recommended) и нажимаем Next.
Выбираем какое приложение мы будем профилировать, это PeopleTrax и кнопка Next. В следующем нажимаем Finish и автоматически запустится профайлер и наше приложение. На экране мы видим программу PeopleTrax. Нажимаем кнопку Get People, ждем завершения работы и Export Data. Закрываем блокнот и программу и профайлер сгенерирует отчет.
Профайлер сгенерировал отчет (*.vsp)
Анализ отчета Sampling метода
В Summary отображается график использования процессора в течение всего времени профилирования. Список Hot Path показывает ветки вызовов, которые проявили наибольшую активность. А в списке Functions Doing Most Individual Work (название которого говорит само за себя) – функции, которые занимали большее время процесса в теле этих функций.
Посмотрев на список Hot Path видим что метод PeopleNS.People.GetNames занимает почти последнее место в ветке вызовов. Его то и можно изучить внимательнее на предмет улучшения производительности. Нажимаем на PeopleNS.People.GetNames и перед нами открывается Function Details.
Это окно содержит две части. Окно расходов предусматривает графическое представление работы функций, и вклад функции и вызывающих ее на количество экземпляров, которые были отобраны. Можно изменить рассматриваемую функцию, нажав на нее мышкой.
Function Code View показывает код метода, когда он доступен и подсвечивает наиболее «дорогие» строки в выбранном методе. Когда выбран метод GetNames видно, что он читает строки из ресурсов приложения используя StringReader, добавляя каждую строку в ArrayList. Нет очевидных способов улучшить эту часть.
Так как PeopleNS.People.GetPeople единственный, кто вызывает GetNames – нажимаем GetPeople. Этот метод возвращает ArrayList объектов PersonInformationNS.PersonInformation с именами людей и компаний, возвращенными методом GetNames. Тем не менее, GetNames вызывается дважды каждый раз, когда создается PersonInformation. (Это и показано желтым и красным выделением). Очевидно, что можно легко оптимизировать метод, создавая списки только один раз вначале метода.
Оптимизированный метод заменит старый при следующей сборке.
Перезапускаем профилирование в текущей сессии нажав Launch with Profiling в окне Performance Explorer. Нажимаем на Get People и Export Data. Закрываем блокнот и программу а профайлер сгенерирует новый отчет.
Чтобы сравнить два отчета – выбираем оба и ПКМ Compare Performance Reports. Колонка дельты показывает разницу в производительности версии Baseline с более поздней Comparison. Выбираем Inclusive Samples % и Apply.
Как видно выигрыш в производительности заметен невооруженным глазом
Профилирование методом Instrumentation
Этот метод полезен при профилировании операций ввода вывода, запись на диск и при обмене данными по сети. Этот метод предоставляет больше информации чем предыдущий, но он несет с собой больше накладных расходов. Бинарники полученные после вставки дополнительного кода получаются больше обычных, и не предназначены для развертывания.
В этот раз мы сосредоточим наш анализ на экспорте данных, в котором список людей записывается в файл блокнота.
Профилирование
В Performance Explorer выбираем Instrumentation и нажмаем Start Profiling. Нажимаем Get People. После загрузки людей ждем 10 секунд и нажмаем Export Data. Закрываем блокнот и программу. Профилировщик сгенерирует отчет.
Анализ
Профилировщик покажет такую картинку:
Мы не получили ту информацию, которую хотели. Отфильтруем данные. Мы специально ждали 10 секунд, чтобы просто отфильтровать ненужные сейчас данные профилирования. Отмечаем с 13-й до конца и нажимаем Filter by selection. Уже другой результат:
Hot Path показывает, что метод Concat занимает много времени (он также первый в списке Functions With Most Individual Work). Нажимаем на Concat, чтобы посмотреть детально информацию о методе.
Видно, что PeopleTrax.Form1.ExportData – единственный метод, который вызывает Concat. Нажимаем PeopleTrax.Form1.ExportData в вызывающих методах (Function calling this function).
В проекте уже есть оптимизированный метод с использованием StringBuilder. В проекте PeopleTrax добавляем переменную компиляции OPTIMIZED_EXPORTDATA. Сохраняем и снова запускаем профайлер и сравниваем отчеты. Сразу видно (да и логически понятно) что мы оптимизировали вызовы Concat (с 6000 до 0 раз).
После запуска приложения на глаз видно заметное улучшение производительности. Очень важно запускать профилирование еще раз, даже есть видимые улучшения. Просмотр новых данных после исправления проблемы может показать другие проблемы в производительности приложений.
Visual Studio provides a variety of profiling tools to help you diagnose different kinds of app performance issues depending on your app type. In this article, we give a quick look at the most common profiling tools.
To see profiling tool support for different app types, see Which tool should I use?
Measure performance while debugging
The profiling tools that you can access during a debugging session are available in the Diagnostic Tools window. The Diagnostic Tools window appears automatically unless you have turned it off. To bring up the window, click Debug / Windows / Show Diagnostic Tools (or press Ctrl + Alt + F2). With the window open, you can select tools for which you want to collect data.
While you are debugging, you can use the Diagnostic Tools window to analyze CPU and memory usage, and you can view events that show performance-related information.
The Diagnostic Tools window is a common way to profile apps, but for Release builds you can also do a post-mortem analysis of your app instead. For more information on different approaches, see Run profiling tools with or without the debugger. To see profiling tool support for different app types, see Which tool should I use?
Tools available in the Diagnostic Tools window or during a debugging session include:
Windows 8 and later is required to run profiling tools with the debugger (Diagnostic Tools window). You can use the post-mortem tools with Windows 7 and later.
Measure performance in release builds
Tools in the Performance Profiler are intended to provide analysis for Release builds. In the Performance Profiler, you can collect diagnostic info while the app is running, and then examine the collected information after the app is stopped (a post-mortem analysis).
Open the Performance Profiler by choosing Debug > Performance Profiler (or Alt + F2).
For more information on using the CPU Usage or Memory usage tool in the Performance Profiler vs. the debugger-integrated tools, see Run profiling tools with or without the debugger.
Tools available in the Performance Profiler include:
To see profiling tool support for different app types, see Which tool should I use?
In some scenarios, the window allows you to select multiple profiling tools. Tools such as CPU Usage may provide complementary data that you can use to help in your analysis. You can also use the command-line profiler to enable scenarios involving multiple profiling tools.
Examine performance using PerfTips
Often, the easiest way to view performance information is to use PerfTips. Using PerfTips, you can view performance information while interacting with your code. You can check information such as the duration of the event (measured from when the debugger was last paused, or when the app started). For example, if you step through code (F10, F11), PerfTips show you the app runtime duration from the previous step operation to the current step.
You can use PerfTips to examine how long it takes for a code block to execute, or how long it takes for a single function to complete.
PerfTips show the same events that also show up in the Events view of the Diagnostic Tools. In the Events view, you can view different events that occur while you are debugging, such as the setting of a breakpoint or a code stepping operation.
If you have Visual Studio Enterprise, you can also see IntelliTrace events in this tab.
Analyze CPU usage
The CPU Usage tool is a good place to start analyzing your app's performance. It will tell you more about CPU resources that your app is consuming. You can use the debugger-integrated CPU Usage tool or the post-mortem CPU Usage tool.
When using the debugger-integrated CPU Usage tool, open the Diagnostics Tool window (if it's closed, choose Debug / Windows / Show Diagnostic Tools). While debugging, open the Summary view, and select Record CPU Profile.
One way to use the tool is to set two breakpoints in your code, one at the beginning and one at the end of the function or the region of code you want to analyze. Examine the profiling data when you are paused at the second breakpoint.
The CPU Usage view shows you a list of functions ordered by longest running, with the longest running function at the top under Top Functions. The Hot Path section shows you the call stack for the functions that are using the most CPU. These lists can help guide you to functions where performance bottlenecks are happening.
The CPU Usage view shows you a list of functions ordered by longest running, with the longest running function at the top. This can help guide you to functions where performance bottlenecks are happening.
Double-click on a function that you are interested in, and you will see a more detailed "Call tree" view, with the selected function highlighted. The table shows columns with data such as the time spent in the function, including called functions (Total CPU), and a second column that shows the time spent in a function, excluding called functions (Self CPU). This data can help you evaluate whether the function itself is a performance bottleneck.
Double-click on a function that you are interested in, and you will see a more detailed three-pane "butterfly" view, with the selected function in the middle of the window, the calling function on the left, and called functions on the right. The Function Body section shows the total amount of time (and the percentage of time) spent in the function body excluding time spent in calling and called functions. This data can help you evaluate whether the function itself is a performance bottleneck.
Analyze memory usage
The Diagnostic Tools window also allows you to evaluate memory usage in your app using the Memory Usage tool. For example, you can look at the number and size of objects on the heap. You can use the debugger-integrated Memory Usage tool or the post-mortem Memory Usage tool in the Performance Profiler.
To analyze memory usage with the Memory Usage tool, you need to take at least one memory snapshot. Often, the best way to analyze memory is to take two snapshots; the first right before a suspected memory issue, and the second snapshot right after a suspected memory issue occurs. Then you can view a diff of the two snapshots and see exactly what changed. The following illustration shows taking a snapshot with the debugger-integrated tool.
When you select one of the arrow links, you are given a differential view of the heap (a red up arrow shows an increasing object count (left) or an increasing heap size (right)). If you click the right link, you get a differential heap view ordered by objects that increased the most in heap size. This can help you pinpoint memory problems. For example, in the illustration below, the bytes used by ClassHandlersStore objects increased by 3,492 bytes in the second snapshot.
If you click the link on the left instead in the Memory Usage view, the heap view is organized by object count; the objects of a particular type that increased the most in number are shown at the top (sorted by Count Diff column).
Analyze resource consumption (XAML)
In XAML apps, such as Windows desktop WPF apps and UWP apps, you can analyze resource consumption using the Application Timeline tool. For example, you can analyze the time spent by your application preparing UI frames (layout and render), servicing network and disk requests, and in scenarios like application startup, page load, and Window resize. To use the tool, choose Application Timeline in the Performance Profiler, and then choose Start. In your app, go through the scenario with a suspected resource consumption issue, and then choose Stop collection to generate the report.
Low framerates in the Visual throughput graph may correspond to visual problems that you see when running your app. Similarly, high numbers in the UI thread utilization graph may also correspond to UI responsiveness issues. In the report, you can select a time period with a suspected performance issue, and then examine the detailed UI thread activities in the Timeline details view (lower pane).
In the Timeline details view, you can find information such as the type of activity (or the UI element involved) along with the duration of the activity. For example, in the illustration, a Layout event for a Grid control takes 57.53 ms.
The tool shows each async operation in a list view. You can see information such as the start time, end time, and total time for an async operation.
The tool shows each async operation in a list view. You can see information such as the start time, end time, and total time for an async operation.
Examine application events
The generic events viewer allows you to view the activity of your application through a list of events, such as module load, thread start, and system configurations, to help better diagnose how your application is performing right within the Visual Studio profiler. This tool is available in the Performance Profiler. Open the Performance Profiler by choosing Debug > Performance Profiler (or Alt + F2).
The tool shows each event in a list view. Columns provide information about each event, such as the event name, timestamp, and process ID.
The tool shows each query in a list view. You can see information such as the query start time and duration.
The tool shows live values for each counter in a list view.
Examine UI performance and accessibility events (UWP)
In your UWP apps, you can enable UI Analysis in the Diagnostic Tools window. The tool searches for common performance or accessibility issues and displays them in the Events view while you are debugging. The event descriptions provide information that can help resolve issues.
Analyze GPU Usage (Direct3D)
In Direct3D apps (Direct3D components must be in C++), you can examine activity on the GPU and analyze performance issues. For more information, see GPU Usage. To use the tool, choose GPU Usage in the Performance Profiler, and then choose Start. In your app, go through the scenario that you're interested in profiling, and then choose Stop collection to generate a report.
When you select a time period in the graphs and choose view details, a detailed view appears in the lower pane. In the detailed view, you can examine how much activity is happening on each CPU and GPU. Select events in the lowest pane to get popups in the timeline. For example, select the Present event to view Present call popups. (The light gray vertical VSync lines can be used as a reference to understand whether certain Present calls missed VSync. There must be one Present call between every two VSyncs in order for the app to steadily hit 60 FPS.)
You can also use the graphs to determine whether there are CPU bound or GPU bound performance bottlenecks.
Analyze performance (JavaScript UWP)
For UWP apps, you can use the JavaScript Memory tool and the HTML UI Responsiveness tool.
The JavaScript Memory tool is similar to the Memory Usage tool available for other app types. You can use this tool to understand memory usage and find memory leaks in your app. For more details about the tool, see JavaScript Memory.
To diagnose UI responsiveness, slow loading time, and slow visual updates in UWP apps, use the HTML UI Responsiveness tool. Usage is similar to the Application Timeline tool for other app types. For more information, see HTML UI responsiveness.
Analyze network usage (UWP)
Select an operation in the summary view to view more details.
For more information, see Network Usage.
Analyze performance (legacy tools)
In Visual Studio 2019, the legacy Performance Explorer and related profiling tools such as the Performance Wizard were folded into the Performance Profiler, which you can open using Debug > Performance Profiler. In the Performance Profiler, the available diagnostics tools depend on the target chosen and the current, open startup project. The CPU Usage tool provides the sampling capability previously supported in the Performance Wizard. The Instrumentation tool provides the instrumented profiling capability (for precise call counts and durations) that was in the Performance Wizard. Additional memory tools also appear in the Performance Profiler.
Which tool should I use?
Here is a table that lists the different tools Visual Studio offers and the different project types you can use them with:
- PerfTip
- Режим Edit & Continue для x64-систем
- Lambda Expression Evaluation в Watch and Immediate Window
- Diagnostic Tools Window
- Live Visual Tree и Live Property Explorer
- Diagnostic Tools Hub
PerfTip
Debugging tips — это маленькие подсказки, всплывающие в ходе отладочной сессии и отображающие значения переменных. Они уже давно присутствуют в VS и, думаю, все с ними знакомы. Теперь вместо них PerfTip выполняет ту же цель: облегчает отладку и повышает её продуктивность. В отличие от Debugging tips, в PerfTip при перемещении по коду отображается информация о тайминге. Раньше нам приходилось собирать тайминги построчно, вставляя код для проведения измерений, вроде класса System.Diagnostics.Stopwatch . Но теперь необходимость в этом отпала: PerfTip умеет измерять время, прошедшее между двумя остановками отладчика. Причём не имеет значения, используете ли вы Step Into, Step Over или Run to Cursor для измерения лишь одной инструкции или целого блока кода. Тайминги отображаются как в PerfTip, так и в виде списка в Diagnostic Tools Window).
PerfTip показывает, что на выполнение метода BuildOpenMenu () ушло 1,357 секунды.
Режим Edit & Continue для x64-систем
Функциональность “edit and continue” появился в VS несколько лет назад, но раньше он мог использоваться только для отладки 32-битных процессов. В этом режиме вы можете модифицировать код, не выходя из отладочной сессии. При этом он перекомпилируется в фоне и сразу готов к использованию. Преимущества очевидны: вы можете построчно выполнять код, анализировать результат, модифицировать, перемещать курсор оператора перехода на позицию перед модифицируемой строкой и вновь её выполнять. И вам даже не понадобится перезапускать отладчик.
Вычисление лямбда-выражений в Watch and Immediate Window
VS 2015 теперь поддерживает вычисление лямбда-выражений в отладочных окнах. Это бывает удобно, например, при анализе коллекций. Допустим, у вас есть список людей на 50 000 записей, и вам нужно найти человека с фамилией Meyer. Раньше это можно было сделать лишь одним способом: добавив коллекцию в окно просмотра (watch window), развернув её и пролистав весь список вручную. Не слишком увлекательный и эффективный процесс, особенно, если список велик. Теперь же вы можете найти нужную запись с помощью простого LINQ-выражения:
Diagnostic Tools Window
В ходе отладки в этом окне можно применять инструменты для профилирования. Чтобы его открыть, выберите пункт Show Diagnostic Tools в меню Debug. По умолчанию в нём будут отображены графики загрузки процессора и памяти. Жёлтые маркеры обозначают работу сборщика мусора. В предыдущих версиях VC все эти данные можно было получить только во время сессии профилирования. Теперь же, вместо многократной процедуры записи и анализа, вы можете наблюдать за поведением системы в реальном времени в процессе отладки. Вы сразу обнаружите всплески в использовании ресурсов, в том числе при сборе мусора, и сможете сопоставить их с отлаживаемым фрагментом кода или действием, выполняемым в интерфейсе.
Другим важным нововведением стал список всех PerfTip. Каждый раз, когда отладчик останавливается и выводит PerfTip, он добавляет новое измерение список в Diagnostic Tools Window. Благодаря этому списку вы можете наблюдать за замерами времени и быстро переходить к соответствующим строкам.
Окно диагностики позволяет не только оценить загрузку процессора и памяти, но и записать одним кликом слепок управляемой памяти. При этом система автоматически подсчитает и отобразит количество объектов в куче, а также их общий размер в байтах. На эти значения можно кликнуть и посмотреть подробный список всех объектов, присутствующих в памяти. Всё это позволяет быстро обнаружить причины каких-либо проблем с памятью, например, утечек. Обратите внимание, что данный инструмент полностью интегрирован в отладчик и не требует его перезапуска.
Live Visual Tree и Live Property Explorer
Это два инструмента, разработанные специально для WPF-приложений (Windows Presentation Foundation) и универсальных приложений. С их помощью можно анализировать запущенную программу, отобразив её в качестве «визуального дерева» (visual tree). Визуальное дерево — это внутреннее представление пользовательского интерфейса, содержащее все видимые элементы приложения. Получается очень похоже на инструменты для веб-разработчиков, запускаемые в браузерах командой «исследовать элемент». Визуальное дерево позволяет одним кликом выбрать элемент пользовательского интерфейса, просмотреть и изменить как сам элемент, так и его свойства. Все изменения сразу будут применены в запущенном приложении. А раньше это можно было сделать только с помощью сторонних приложений, например, Snoop или WPF Inspector.
На иллюстрации ниже представлен пример визуального дерева WPF-приложения. Слева представлена программа Family.Show, её референсная WPF-реализация создана компанией Vertigo и доступна для скачивания на Codeplex. На иллюстрации выделена фотография принца Чарльза, и её свойства отображены справа в Live Visual Tree. Дерево начинается с класса MainWindow и развёрнуто вплоть до выбранного объекта. А в колонке справа отображается количество дочерних объектов для каждого визуального элемента.
Если кликнуть правой кнопкой на объекте внутри дерева, то появится контекстное меню. В нём есть полезные пункты Go to source и Show Properties. Первый открывает файл XAML, содержащий определение элемента. А второй пункт запускает Live Property Explorer.
Здесь представлены свойства элемента и их значения. При этом Live Property Explorer позволяет группировать свойства по происхождению их значений. Из иллюстрации видно, что значения бывают по умолчанию, вычисленные, унаследованные и локальные. Также они могут быть получены из файла определения стилей XAML. Все значения можно изменять прямо в Live Property Explorer и сразу наблюдать, какой эффект это оказывает на работающее приложение.
Diagnostic Tools Hub
Этот инструмент появился в Visual Studio 2013. Запустить его можно через Debug -> Start Diagnostic Tools without Debugging, он является точкой запуска для всех инструментов, имеющих отношение к производительности и диагностике. Diagnostic Tools Hub представляет собой набор многочисленных маленьких инструментов, каждый из которых измеряет, записывает, вычисляет и отображает в окне Visual Studio только какой-то один параметр. Все инструменты используют единую структуру визуализации данных в виде временной шкалы с подробностями по каждой записи. Шкала представляет собой гистограмму основного измерения, на которой могут отображаться пользовательские маркеры для особых событий или значений. Можно просматривать данные более подробно, при этом форма отображения будет разной для всех инструментов. Так что при желании можно более детально изучить параметры любого измерения и вывести общую информацию в виде круговой диаграммы. Поскольку формат вывода у всех инструментов общий, то в течение одной сессии можно одновременно запускать несколько инструментов, просматривая результаты их измерений в компактном виде. Например, можно скомбинировать индикатор активности пользовательского интерфейса и уровень загрузки процессора. Раньше эти инструменты были заточены, в основном, под приложения для Windows Store. Благодаря своей простоте и унифицированному дизайну набор инструментов очень часто обновляется, и в VS 2015 многие из них поддерживают и другие технологии, например Windows Presentation Foundation.
Старый профилировщик в Visual Studio, умевший измерять загрузку процессора и памяти, не вписывался в концепцию маленьких диагностических инструментов со стандартным форматом вывода данных. Поэтому ради обратной совместимости его интегрировали в Diagnostic Tools Hub. Создатели VS планируют постепенно распределить функциональность профилировщика по нескольким отдельным инструментам, доступным из хаба.
Итак, какой же набор инструментов представлен в Diagnostic Tools Hub в Visual Studio 2015:
- Application Timeline: позволяет мониторить активность UI-потока приложений, основанных на XAML
- CPU Usage: использование процессора ()
- GPU Usage: отображает выполняемые графической картой инструкции для DirectX-приложений
- Memory Usage: отображает потребление памяти для обнаружения утечек
- Performance Wizard: старый профилировщик Visual Studio
- Energy Consumption: отображает расчётное потребление энергии для мобильных устройств
- HTML UI Responsiveness: позволяет мониторить активность UI-потока приложений, основанных на HTML
- JavaScript Memory: анализирует использование памяти в HTML-приложениях
- Network: профилирует сетевой трафик
Далее приведён пример подробной детализации той же сессии. События разбиты по категориям и отображены в виде полосок, длина которых соответствует продолжительности каждого события. Это позволяет очень легко оценить, сколько времени у вас занял парсинг, вывод макета, чтение и запись с диска или сборка мусора. Некоторые события можно развернуть в виде дерева для ещё более подробного изучения.
Заключение
В Visual Studio 2015 есть много замечательных возможностей по отладке, диагностике и профилированию, которые могут помочь поднять производительность разработчика. Все упомянутые инструменты есть в каждой редакции VS, вплоть до бесплатной Visual Studio Community Edition. Здесь вы найдёте для себя всё необходимое. При этом впервые в истории VS профилирование можно осуществлять прямо во время отладки. В Visual Studio 2015 профилирование приложений объединено с процессом удобной отладки, ежедневно применяемой разработчиками.
Читайте также: