Visual studio profiler как пользоваться

Обновлено: 05.07.2024

Это серия статей, которые я пишу, которые охватывают четыре различных метода профилирования приложений в Visual Studio. Эти методы:

Производительность приложения — это ключевой элемент, который следует проанализировать и оптимизировать до фактического публичного выпуска. Microsoft Visual Studio 2010 поставляется со встроенными инструментами профилирования, которые предлагают разработчикам возможность анализировать производительность своих приложений на основе множества факторов. Динамический анализ кода (профилирование) позволяет находить части приложения, которые необходимо оптимизировать для достижения лучшей производительности.

ПРИМЕЧАНИЕ. Инструменты профилирования недоступны в выпусках Visual Studio 2010 Express и Professional. Подробности здесь .

Настройка примера приложения

Перед выполнением фактического анализа я настроил пример многопоточного приложения, которое будет выполнять набор операций с данными (ввод-вывод, извлечение данных через веб-сервис). Это простое консольное приложение с
методом Main и дополнительным
методом Get , которое получает фактические данные из Интернета.

Метод
Get, о котором я говорю, выглядит следующим образом:

Это тот же метод, который я использовал для тестирования в
этой статье, и мне нравится использовать его в качестве примера ресурсоемкого процесса. В моем приложении я собираюсь запустить несколько потоков, которые будут вызывать этот метод и отображать (и записывать в файл) полученные данные.

Так что для
метода Main в моем консольном приложении я использую код ниже:

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

Все готово для анализа производительности, поэтому перейдем к следующему шагу

Отслеживание показателей эффективности

Чтобы начать анализ, вам нужно запустить мастер производительности (из меню анализа):

Вам будет предложено выбрать метод анализа из четырех возможных:

Я расскажу о каждом из возможных методов профилирования в моих следующих статьях, но здесь я специально рассмотрю выборку процессора

Выполнение операции

CPU sampling collects information on how the application impacts the CPU performance, both as a single unit and as a set of separate function calls. It allows the developer to see what parts of the code are the most expensive, CPU-wise.

The next step in the Performance Wizard is choosing the project or application that needs to be profiled.

Since we are working with the current console application project, it is selected as the default item. If the solution that is currently open contains more than one project, each of them will be listed there and you will be able to select more than one project to track performance for.

Chances are that you aren’t launching Visual Studio as an administrator (with elevated permissions). In this case, once you decide to start the profiling session, you could encounter a message like this:

Click Yes and the profiling session will be started. The application will run just like any other time:

However, Visual Studio will be in process of profiling the current application:

Analyzing the results

Once completed, the final report should look similar to this:

And here is the place where you can take a look at what parts of your code impact the CPU performance most.

First of all, the Hot Path is showing you the function call path that is the most “expensive” – the one that has the biggest impact on the CPU load for your specific application:

In my case, this would be Trace.WriteLine inside the Get method, since it is called very often — for every city that is inside the list the string is printed out on the screen and in a text file. If you click on Trace.WriteLine in this list, you will open up a more detailed report on the function call:

The detailed report can give you information on CPU loads based on various calls inside the researched function. Also, you can clearly see the code part that is the most consuming:

You are able to switch between the sample percentage and the actual number of samples by changing the view from Inclusive Samples % to Inclusive Samples. Now you might be asking what Inclusive might mean here.

When a sample is taken, basically it grabs a snapshot of the call stack. When the analyzed function was on top of the stack, it counts towards the inclusive sample. If it was anywhere else in the stack, it counts towards the inclusive sample.

In the main report window, you are also able to see the functions doing the most individual work (called most often). Here, only the exclusive sample is called, therefore when the function was on top of the call stack.

NOTE: The data presented in the profiling report relates to the CPU as a whole. Via the default CPU sampling report you are not able to see the performance based on specific cores, for a multicore system.

В целом, действия, описанные в этом пошаговом руководстве, можно применять к приложениям на C и C++. Для каждого языка программирования необходимо соответствующим образом настроить среду сборки.

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

Однако более высокий уровень детализации приводит к увеличению объема собираемых данных. Порой при профилировании с инструментированием создаются файлы данных очень большого размера. Кроме того, более высока вероятность того, что инструментирование отрицательно скажется на производительности приложения. Дополнительные сведения см. в статьях Общие сведения о значениях данных инструментирования в средствах профилирования и Общие сведения о значениях выборочных данных.

Профилировщик Visual Studio позволяет ограничить объем собираемых данных. В этом пошаговом руководстве приведен пример ограничения сбора данных с помощью интерфейсов API профилировщика. Профилировщик Visual Studio предоставляет интерфейс API для управления сбором данных из приложения.

Для машинного кода интерфейсы API профилировщика Visual Studio находятся в файле VSPerf.dll. Файл заголовка VSPerf.h и библиотека импорта VSPerf.lib расположены в каталоге Microsoft Visual Studio\2017\Team Tools\Performance Tools\PerfSDK. Для 64-разрядных приложений используется папка Microsoft Visual Studio\2017\Team Tools\Performance Tools\x64\PerfSDK.

Для управляемого кода интерфейсы API находятся в файле Microsoft.VisualStudio.Profiler.dll. Эта библиотека DLL находится в каталоге Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools. Для 64-разрядных приложений используется папка Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\x64. Дополнительные сведения см. в статье о пространстве имен Microsoft.VisualStudio.Profiler.

предварительные требования

В этом пошаговом руководстве предполагается, что используемая среда разработки настроена для отладки и выборки. В следующих разделах представлены общие сведения о предварительных требованиях:

По умолчанию при запуске профилировщика он выполняет сбор данных на глобальном уровне. При включении в начало программы указанного ниже кода профилирование на глобальном уровне отключается.

Сбор данных можно отключить из командной строки, не вызывая API. В следующих шагах предполагается, что среда сборки из командной строки настроена для работы как средств профилирования, так и средств разработки. В том числе настроены параметры, необходимые для работы средств VSInstr и VSPerfCmd. См. дополнительные сведения о средствах профилирования командной строки.

Ограничение сбора данных с помощью интерфейсов API профилировщика

Создание кода для профилирования

При сборке должна использоваться библиотека Microsoft.VisualStudio.Profiler.dll, расположенная в каталоге Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools.

Скопируйте и вставьте в проект следующий код:

Сбор и просмотр данных в интегрированной среде разработки Visual Studio

Откройте интегрированную среду разработки Visual Studio. В меню Анализ наведите указатель мыши на пункт Профилировщик и щелкните Новый сеанс производительности.

Добавьте скомпилированный двоичный файл в список Целевые объекты в окне Обозреватель производительности. Щелкните правой кнопкой мыши узел Целевые объекты и выберите команду Добавить конечный двоичный файл. Укажите местоположение двоичного файла в диалоговом окне Добавление целевого двоичного файла и нажмите кнопку Открыть.

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

Профилировщик выполнит инструментирование, запустит двоичный файл и создаст файл отчета о производительности. Файл отчета о производительности отображается в узле Отчеты обозревателя производительности.

Откройте созданный файл отчета о производительности.

Сбор и просмотр данных из командной строки

Скомпилируйте отладочную версию примера кода, созданного ранее в процедуре "Создание кода для профилирования" этого пошагового руководства.

В случае профилирования управляемого приложения установите соответствующие переменные среды с помощью следующей команды:

VsPerfCLREnv /traceon.

Введите следующую команду: VSInstr <filename>.exe

Введите следующую команду: VSPerfCmd /start:trace /output:<filename>.vsp

Введите следующую команду: VSPerfCmd /globaloff.

Введите следующую команду: VSPerfCmd /shutdown.

Введите следующую команду: VSPerfReport /calltrace:<filename>.vsp

В текущем каталоге создается CSV-файл, содержащий результирующие данные производительности.

Visual Studio предоставляет широкий набор средств профилирования для выявления различных типов проблем с производительностью в зависимости от типа приложения. В этой статье мы кратко рассмотрим наиболее распространенные средства профилирования.

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

Измерение производительности во время отладки

Средства профилирования, которыми можно воспользоваться во время сеанса отладки, доступны в окне "Средства диагностики". Окно "Средства диагностики" появится автоматически, если вы не отключали эту функцию. Чтобы открыть окно, щелкните Отладка | Окна | Показать средства диагностики или нажмите сочетание клавиш CTRL + ALT + F2. В открытом окне можно выбирать средства, для которых требуется собрать данные.

При отладке можно использовать окно Средства диагностики для анализа использования ЦП и памяти, а также просматривать события, отображающие сведения, связанные с производительностью.

Использование окна Средства диагностики является распространенным способом профилирования приложений, но для сборок выпуска вместо этого также можно выполнять последующий анализ приложения. Дополнительные сведения о различных подходах см. в статье Выполнение средств профилирования с отладчиком и без него. См. дополнительные сведения о рекомендуемом средстве профилирования с поддержкой разных типов приложений.

Средства, доступные в окне "Средства диагностики" или во время сеанса отладки:

Для запуска средств профилирования с отладчиком (окно Средства диагностики) требуется Windows 8 и более поздние версии. Вы можете использовать средства последующего анализа с Windows 7 и более поздними версиями.

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

Средства в Профилировщике производительности предназначены для анализа сборок выпуска. В профилировщике производительности можно собрать диагностические сведения во время работы приложения, а затем проанализировать их после его остановки (последующий анализ).

Откройте Профилировщик производительности, последовательно выбрав Отладка > Профилировщик производительности (или нажмите клавиши ALT + F2).

Дополнительные сведения об использовании средства "Загрузка ЦП" или "Использование памяти" в Профилировщике производительности и средств, встроенных в отладчик, см. в статье Запуск средств профилирования с отладчиком или без него.

Средства, доступные в Профилировщике производительности:

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

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

Проверка производительности с помощью PerfTips

Зачастую просмотреть сведения о производительности проще всего с помощью PerfTips. Используя подсказки, вы можете просматривать сведения о производительности непосредственно при взаимодействии с кодом. Можно проверить такие сведения, как длительность события (измеряется с момента последней приостановки отладчика или с момента запуска приложения). Например, при пошаговом выполнении кода (F10, F11) PerfTips отображает длительность выполнения приложения с операции на предыдущем шаге до текущего шага.

PerfTips можно использовать для проверки длительности выполнения блока кода или времени, необходимого для завершения работы одной функции.

PerfTips отображает те же события, которые также выводятся в представлении События средств диагностики. В представлении События приводятся различные события, которые возникают при отладке, например операция задания точки останова или пошагового выполнения кода.

Если у вас установлен выпуск Visual Studio Enterprise, на этой вкладке вы можете увидеть события IntelliTrace.

Анализ использования ЦП

Средство загрузки ЦП является хорошей отправной точкой для анализа производительности приложения. С его помощью вы получите дополнительные сведения о ресурсах ЦП, используемых приложением. Вы можете использовать средство "Загрузка ЦП", встроенное в отладчик, или средство "Использование ЦП"последующего анализа.

При использовании средства "Загрузка ЦП", встроенного в отладчик, откройте окно "Средства диагностики" (если оно закрыто, выберите Отладка > Окна > Показать средства диагностики). Во время отладки откройте представление Сводка и выберите Запись профиля ЦП.

Единственный способ использовать средство — установить в коде две точки останова: одну в начале и одну в конце функции и области кода, которые требуется проанализировать. Проверьте данные профилирования во время приостановки во второй точке останова.

В представлении Загрузка ЦП отображается список функций, упорядоченных по самой продолжительно выполняющейся (эта функция расположена в верхней части). Это поможет переходить к функциям, где наблюдаются проблемы с производительностью.

Дважды щелкните нужную функцию, после чего откроется подробное представление с тремя панелями (представление "бабочки"): выбранная функция будет находиться в центре окна, вызываемая функция — в левой части, а вызывающая функция — в правой. В разделе Тело функции также показан общий объем времени (и доля времени), затраченного в теле функции за исключением времени, затраченного в вызываемых и вызывающих функциях. Эти данные помогут оценить, оказывает ли негативное влияние на производительность сама функция.

Анализ данных об использовании памяти

В окне средств диагностики также можно оценить использование памяти в приложении с помощью средства Использование памяти. Например, можно узнать число и размер объектов в куче. В Профилировщике производительности можно использовать средство "Использование памяти", встроенное в отладчик или средство "Использование памяти" для последующего анализа.

Для анализа использования памяти с помощью средства использования памяти необходимо сделать хотя бы один моментальный снимок памяти. Часто наилучшим способом анализа памяти является создание двух снимков: первый создается непосредственно перед возникновением потенциальной проблемы с памятью, а второй — сразу же после возникновения этой проблемы. Затем можно просмотреть различия двух моментальных снимков и точно определить, что изменилось. На следующем рисунке показано создание моментального снимка с помощью средства, встроенного в отладчик.

При выборе одной из ссылок со стрелкой откроется разностное представление кучи (красная стрелка вверх показывает растущее количество объектов (слева) или увеличивающийся размер памяти (справа)). Если щелкнуть ссылку справа, откроется разностное представление кучи, упорядоченное по объектам, которые привели к максимальному увеличению размера кучи. Это может помочь выявить проблемы с памятью. Например, на следующем рисунке байты, используемые объектами ClassHandlersStore , увеличены на 3 492 байт на втором моментальном снимке.

Если в представлении Использование памяти щелкнуть ссылку слева, представление кучи будет упорядочено по количеству объектов. Объекты определенного типа, количество которых максимально выросло, отображаются в верхней части (отсортированы по столбцу Count Diff (Разница числа)).

Анализ использования ресурсов (XAML)

В приложениях XAML, таких как классические приложения WPF и приложения универсальной платформы Windows, можно анализировать потребление ресурсов, используя средство "Временная шкала приложения". Например, вы можете проанализировать время, затраченное приложением на подготовку кадров пользовательского интерфейса (макет и обработка), обработку запросов от сети и дисков, а также на такие сценарии, как запуск приложения, загрузка страницы и изменение размера окон. Чтобы использовать это средство, выберите Временная шкала приложения в профилировщике производительности и нажмите кнопку Запустить. В приложении выполните сценарий с предполагаемой проблемой потребления ресурсов, а затем щелкните Остановка сбора, чтобы создать отчет.

Низкие значения частоты кадров на графе Пропускная способность визуализации может означать наличие проблем визуализации, присутствующих при запуске приложения. Аналогично, высокие показатели на графе Использование потока пользовательского интерфейса могут соответствовать проблемам со скоростью отклика пользовательского интерфейса. В отчете можно выбрать временной период предполагаемой проблемы производительности и затем в представлении "Подробная временная шкала" (нижняя панель) изучить подробные действия потока пользовательского интерфейса.

В представлении "Подробная временная шкала" находятся такие сведения, как тип действия (или затронутый элемент пользовательского интерфейса), а также длительность действия. Например, на рисунке событие Макета для элемента управления сетки длится 57,53 мс.

Дополнительные сведения см. в разделе Временная шкала приложения.

Изучение событий приложения

Средство просмотра общих событий позволяет просматривать действия приложения с помощью списка событий, таких как загрузка модуля, запуск потока и конфигурации системы. Это позволяет эффективнее диагностировать работу приложения в профилировщике Visual Studio. Это средство доступно в Профилировщике производительности. Откройте Профилировщик производительности, последовательно выбрав Отладка > Профилировщик производительности (или нажмите клавиши ALT + F2).

Это средство отображает каждое событие в представлении списка. Столбцы содержат сведения о каждом событии, например имя события, метку времени и идентификатор процесса.

Средство отображает все асинхронные операции в представлении списка. Вы можете просмотреть такие сведения, как время начала и окончания, а также общее время асинхронной операции.

Это средство отображает каждый запрос в представлении списка. Вы можете просмотреть такие сведения, как время начала и длительность запроса.

Средство отображает текущие значения для каждого счетчика в представлении списка.

Проверка событий производительности и доступности пользовательского интерфейса (UWP)

В приложениях UWP в окне Средства диагностики можно включить параметр Анализ пользовательского интерфейса. Средство выполняет поиск общих проблем производительности или доступности и во время отладки отображает их в представлении События. В описаниях событий содержатся сведения, которые могут помочь при устранении неполадок.

Анализ использования GPU (Direct3D)

В приложениях Direct3D (компоненты Direct3D должны быть в C++) можно изучить действие GPU и проанализировать проблемы производительности. Дополнительные сведения см. в разделе Использование GPU. Чтобы использовать это средство, выберите Использование GPU в профилировщике производительности и нажмите кнопку Запустить. В приложении выполните нужные действия профилирования, а затем щелкните Остановка сбора, чтобы создать отчет.

Выберите период времени на графах и щелкните Просмотреть сведения. В нижней панели появится представление подробных сведений. В этом представлении можно узнать, сколько событий происходит в каждом ЦП и графическом процессоре. Выбирайте события в самой нижней панели, чтобы открывать всплывающие окна на временной шкале. Например, выберите событие Присутствующие, чтобы просмотреть всплывающие окна по вызову Присутствующий. (Светло-серые вертикальные линии Vsync можно использовать в качестве точек отсчета для понимания того, пропустили ли вертикальную синхронизацию определенные вызовы с типом Присутствующий. Чтобы приложение выводило изображение со стабильной частотой в 60 кадров/с, между каждыми двумя вертикальными синхронизациями должен выполняться один вызов с типом Присутствующий.

Графы также можно использовать для определения узких мест производительности ЦП или GPU.

Анализ производительности (JavaScript UWP)

Для приложений UWP можно использовать средство "Память JavaScript" и средство "Скорость реагирования пользовательского интерфейса HTML".

Средство "Память JavaScript" аналогично средству "Использование памяти", доступному для других типов приложений. Это средство можно использовать для анализа использования памяти и поиска утечек памяти в приложении. Дополнительные сведения об этом средстве см. в разделе Память JavaScript.

Для диагностики скорости отклика пользовательского интерфейса, медленной загрузки и медленных визуальных обновлений в приложениях UWP используйте средство "Скорость реагирования пользовательского интерфейса HTML". Это средство аналогично инструменту "Временная шкала приложения" для других типов приложений. Дополнительные сведения см. в разделе Скорость реагирования пользовательского интерфейса HTML.

Анализ использования сети (UWP)

Выберите операцию в представлении "Сводка", чтобы просмотреть более подробные сведения.

Дополнительные сведения см. в разделе Использование сети.

Анализ производительности (устаревшие инструменты)

В Visual Studio 2019 устаревший Обозреватель производительности и связанные средства профилирования, такие как мастер производительности, были объединены в Профилировщик производительности, который можно открыть с помощью команды Отладка > Профилировщик производительности. В Профилировщике производительности доступные средства диагностики зависят от выбранного целевого объекта и текущего открытого запускаемого проекта. Инструмент "Загрузка ЦП" предоставляет возможности выборки, ранее поддерживаемые мастером производительности. Средство инструментирования предоставляет возможность профилирования с инструментированием (для точного числа и длительности вызовов), которая была представлена в мастере производительности. В Профилировщике производительности также содержатся дополнительные средства памяти.

Какие средства следует использовать?

Ниже приведена таблица со списком различных средств, предлагаемых в Visual Studio, и различных типов проектов, в которых эти средства можно использовать.

Как понять профилирование данных в C ++ в Windows, когда компилятор вставляет много кода? То есть Я, конечно, хочу измерить код, который действительно запускается, поэтому по определению я собираюсь измерить оптимизированную сборку кода. Но похоже, что ни одному из инструментов, которые я пытаюсь использовать, не удается разрешить встроенные функции.

Я пробовал как сэмплерный профилировщик в Visual Studio 2017 Professional, так и VTune 2018. Я попытался включить /Zo , но это, похоже, не имеет никакого влияния.

Вот пример кода:

Скомпилируйте его с помощью Visual Studio в режиме выпуска. Или в командной строке попробуйте cl /O2 /Zi /Zo /EHsc main.cpp , Затем попробуйте профилировать его с помощью CPU Sampling Profiler в Visual Studio. В большинстве случаев вы увидите что-то вроде этого:

РЕДАКТИРОВАТЬ: Я только что попытался скомпилировать минимальный пример выше с помощью clang, и он дает другие, но все же неудовлетворительные результаты? Я скомпилировал clang 6.0.0 (trunk), собрал из LLVM rev 318844 и clang rev 318874. Затем я скомпилировал свой код с clang++ -std=c++17 -O2 -g main.cpp -o main.exe и снова запустите полученный исполняемый файл с помощью Sampling Profiler в Visual Studio, в результате:

Так что теперь я вижу burn функция, но потерял информацию исходного файла. Так же uniform_real_distribution до сих пор нигде не показывается.

РЕДАКТИРОВАТЬ 2: Как предложено в комментариях, я теперь также опробовал clang-cl с теми же аргументами, что и cl выше, т.е. clang-cl.exe /O2 /Zi /Zo /EHsc main.cpp , Это дает те же результаты, что и clang.exe , но мы также получаем несколько рабочих исходных сопоставлений:

РЕДАКТИРОВАТЬ 3: Я первоначально думал, что Clang волшебным образом решит эту проблему. К сожалению, нет. Большинство встроенных кадров все еще отсутствуют 🙁

Решение

К счастью, у меня уже установлены три разные версии VS. Я могу рассказать вам больше информации о поддержке функции встроенных функций, как описано в статья Вы ссылались:

VS Community 2013 Update 5 не поддерживает показ встроенных функций, даже когда я указываю / d2Zi +. Кажется, что он поддерживается только в VS 2013 Premium или Ultimate.
VS Community 2015 Update 3 поддерживает показ встроенных функций (функция обсуждалась в статья ). По умолчанию указывается / Zi. / Zo включен неявно с / Zi , так что вам не нужно указывать это явно. Поэтому вам не нужно VS 2015 Premium или Ultimate.
VS Community 2017 с последним обновлением не поддерживает показ встроенных функций независимо от / Zi и / Zo. Кажется, что он поддерживается только в VS 2017 Professional и / или Enterprise.

В блоге VC ++ не сообщается о каких-либо улучшениях профилировщика выборки VS 2017, поэтому я не думаю, что он лучше, чем профилировщик VS Community 2015.

Обратите внимание, что разные версии компилятора могут принимать разные решения по оптимизации. Например, я заметил, что VS 2013 и 2015 не содержат burn функция.

Используя VS Community 2015 Update 3, я получаю результаты профилирования, очень похожие на показанные в третье изображение и тот же код выделен.

Теперь я расскажу, как эта дополнительная информация может быть полезна при интерпретации результатов профилирования, как вы можете получить это вручную, приложив дополнительные усилия, и как интерпретировать результаты, несмотря на встроенные функции.

Как понять C ++ профилирование данных в Windows, когда много
код вставляется компилятором?

Профилировщик VS будет относить затраты только к функциям, которые не были встроены. Для функций, которые были встроены, затраты будут добавлены и включены в некоторую функцию вызывающего абонента, которая не была встроена (в этом случае burn функция).

Сложив предполагаемое время выполнения не встроенных вызываемых функций из burn (как показано на рисунке), мы получаем 31,3 + 22,7 + 4,7 + 1,1 = 59,8%. Кроме того, расчетное время выполнения Function Body как показано на рисунке 40,2%. Обратите внимание, что 59,8% + 40,2% = 100% времени, проведенного в burn , так, как это должно быть. Другими словами, 40,2% времени, проведенного в burn было потрачено в теле функции и любых функций, которые были встроены в него.

40,2% это много. Следующий логический вопрос: какие функции встроены в burn ? Используя эту функцию, которую я обсуждал ранее (которая доступна в VS Community 2015), я могу определить, что следующие функции были встроены в burn :

Без этой функции вам придется вручную разбирать испускаемый исполняемый двоичный файл (либо с помощью отладчика VS, либо с помощью DUMPBIN ) и найдите все x86 call инструкции. Сравнивая это с функциями, вызываемыми в исходном коде, вы можете определить, какие функции были встроены.

Возможности профилировщика выборки VS до VS 2017 включительно заканчиваются на этом этапе. Но это действительно не существенное ограничение. Как правило, не многие функции встроены в одну и ту же функцию из-за жесткого верхнего предела, налагаемого компилятором на размер каждой функции. Поэтому, как правило, можно вручную проверить исходный код и / или код сборки каждой встроенной функции и посмотреть, значительно ли этот код повлияет на время выполнения. Я сделал это, и вполне вероятно, что тело burn (исключая встроенные функции), и эти две встроенные функции в основном отвечают за эти 40,2%.

Другие решения

Я не уверен, правильно ли я понял проблему, описанную в вашем вопросе. На вашем сайте я бы попробовал / Ob0 Опция компилятора Visual C ++. Он должен отключить встроенное расширение.

/ Ob Опция компилятора управляет встроенным расширением функций. Должно следовать число 0, 1 или же 2.

0 Отключает встроенные расширения. По умолчанию расширение выполняется по усмотрению компилятора для всех функций, часто называемых автоматически встроенными.

1 Разрешает расширение только функций, помеченных как inline, __inline или __forceinline, или в функции-члене C ++, определенной в объявлении класса.

2 Значение по умолчанию. Позволяет расширять функции, помеченные как inline, __inline или __forceinline, и любые другие функции, выбранные компилятором.

/ Ob2 действует, когда / O1, / O2 (Минимизировать размер, максимизировать скорость) или / Ox (Включить большинство оптимизаций скорости).

Эта опция требует, чтобы вы включили оптимизацию, используя / O1, / O2, / Ox, или же / Og.

Откройте диалоговое окно страниц свойств проекта. Для получения дополнительной информации см. Работа со свойствами проекта.
Разверните Свойства конфигурации, C / C ++ и выберите Оптимизация.
Измените свойство «Расширение встроенной функции».

Для получения дополнительной информации прочитайте статью / Ob (расширение встроенной функции)

Читайте также: