Run profiling tools on release or debug builds (C#, Visual Basic, C++, F#)

Visual Studio offers a choice of performance measurement and profiling tools. Some tools, like CPU Usage and Memory Usage, can run either on release builds or while debugging your app (debug build). Tools that appear in the Diagnostics Tools window run only during a debugging session. Tools that appear in the Performance Profiler run without the debugger, typically on release builds, and you analyze the results after you choose to stop and collect data (for post-mortem analysis).

The Performance Profiler and the debugger-integrated Diagnostic Tools provide different information and experiences. While using the Diagnostic Tools, the debugger shows you variable values and lets you use breakpoints.

Release build performance numbers in the Performance Profiler are the most precise and accurate. These tools give you results closer to the end-user experience. Typically, this is the preferred method for using the profiling tools. However, there may be scenarios where using the debugger in a debug build may help to narrow down the performance problem, especially if you want to use debugger features such as breakpoints and code stepping.

To help you decide between using the profiling tools in release or debug builds, consider the following:

• Release builds provide optimizations like inlining function calls and constants, pruning unused code paths, and storing variables in ways that can't be used by the debugger. Performance numbers in debug builds are less accurate, because debug builds lack these optimizations.
• In addition to differences between release builds and debug builds, the debugger itself changes performance times, as it does necessary debugger operations like intercepting exception and module load events.
• For performance problems caused by CPU-intensive calls, there might be considerable performance differences between release and debug builds. Check to see whether the CPU performance issue exists in release builds.
• External performance problems, like file I/O or network responsiveness issues, won't look much different in a release build or a debug build.
• If the problem occurs only with debug builds, you probably don't need to run the tools with release builds.
• Some tools, such as the .NET Object Allocation tool, are only available in the Performance Profiler (non-debugger scenarios).

Collect profiling data on release builds

To collect performance data on release builds, run the Performance Profiler tools.

1. With a project open in Visual Studio, set the solution configuration to Release, and select Local Windows Debugger (or Local Machine) as the deployment target.

2. Select Debug > Performance Profiler, or press Alt+F2.

3. On the diagnostic tools launch page, select one or more tools to run. Only the tools that are applicable to the project type, operating system, and programming language are shown. Select Show all tools to also see tools that are disabled for this diagnostic session.

   

4. To start the diagnostic session, select Start.

   While the session is running, some tools show graphs of real-time data on the diagnostic tools page, and might show options to pause and resume data collection.

   

5. To end the diagnostic session, select Stop Collection.

   The analyzed data appears on the Report page.

   For more information about the tools available for use in release builds and how to analyze the reports, see:

   • Analyze performance by using CPU profiling
   • Analyze memory usage
   • Analyze memory usage for .NET code
   • Analyze instrumentation data
   • Analyze .NET Counters
   • Analyze performance of .NET asynchronous code
   • Analyze database performance
   • View events
   • Analyze GPU usage

   Note

   Use relaunch to skip the launch page and automatically run with your previous settings with Alt+F2 or by clicking Debug > Performance Profiler.

6. (Optional) Save the report, and then you can open it later from the Recently Opened Sessions list on the Diagnostic Tools launch page.

   

Collect profiling data while debugging

When you start debugging in Visual Studio by selecting Debug > Start Debugging, or pressing F5, the Diagnostic Tools window appears by default. To open it manually, select Debug > Windows > Show Diagnostic Tools. The Diagnostic Tools window shows information about events, process memory, CPU usage, and .NET Counters.

• Use the Settings icon in the toolbar to select whether to view CPU Usage, Memory Usage, or .NET Counters.

• Select Settings in the Settings drop-down list to open the Diagnostic Tools Property Pages with more options.

• If you're running Visual Studio Enterprise, you can enable or disable IntelliTrace by going to Tools > Options > IntelliTrace.

The diagnostic session ends when you stop debugging.

For more information about the tools available while debugging, see:

• Measure application performance by analyzing CPU usage
• Measure memory usage in Visual Studio
• Analyze .NET Counters

Events tab

During a debugging session, the Events tab of the Diagnostic Tools window lists the diagnostic events that occur. The category prefixes Breakpoint, File, and others, let you quickly scan the list for a category, or skip the categories you don't care about.

Use the Filter drop-down list to filter events in and out of view, by selecting or clearing specific categories of events.

Use the search box to find a specific string in the event list. Here are the results of a search for the file name model that matched three events:

For more information, see Searching and filtering the Events tab of the Diagnostic Tools window.

Collect profiling data from the command line

To measure performance data from the command line, you can use VSDiagnostics.exe, which is included with either Visual Studio or the Remote Tools. This is useful for capturing performance traces on systems where Visual Studio isn't installed, or for scripting the collection of performance traces. For detailed instructions, see Measure application performance from the command line.