Understand performance collection methods
Applies to: 
Visual Studio 
Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
Visual Studio Profiling tools provide five methods for collecting performance data. This article describes the different methods and suggests scenarios in which collecting data with a particular method might be appropriate.
Note
Enhanced security features in Windows 8 and Windows Server 2012 required significant changes in how the Visual Studio profiler collects data on these platforms. UWP apps also require new collection techniques. See Performance tools on Windows 8 and Windows Server 2012 applications.
| Method | Description |
|---|---|
| Sampling | Collects statistical data about the work done by an app. |
| Instrumentation | Collects detailed timing information about each function call. |
| Concurrency | Collects detailed information about multithreaded apps. |
| .NET memory | Collects detailed information about .NET memory allocation and garbage collection. |
| Tier interaction | Collects information about synchronous ADO.NET function calls to a SQL Server database. Any edition of Visual Studio can collect tier-interaction profile data. However, you can view that data only in Visual Studio Enterprise. |
By using some of the profiling methods, you can also collect additional data like software and hardware performance counters. For more information, see Collect additional performance data.
Sampling
The sampling profiling method collects statistical data about the work that an app does during a profiling run. The sampling method is lightweight and has little effect on the execution of app methods.
Sampling is the default method of the Visual Studio Profiling tools. It's useful for the following tasks:
- Initial explorations of your app's performance
- Investigating performance issues that involve the utilization of the microprocessor (CPU)
The sampling profiling method interrupts the computer CPU at set intervals and collects the function call stack. Exclusive sample counts are incremented for the function that is running. Inclusive counts are incremented for all the calling functions on the call stack. Sampling reports present the totals of these counts for the profiled modules, functions, source-code lines, and instructions.
By default, the profiler sets the sampling interval to CPU cycles. You can change the interval type to another CPU performance counter or set the number of counter events for the interval. You can also collect tier-interaction profiling (TIP) data. This data provides information about the queries made to a SQL Server database through ADO.NET.
Collect performance statistics by using sampling
Understand sampling data values
Instrumentation
The instrumentation profiling method collects detailed timing for the function calls in a profiled app. Instrumentation profiling is useful for these tasks:
- Investigating input/output bottlenecks such as disk I/O
- Close examination of a particular module or set of functions
The instrumentation method injects code into a binary file. The code captures timing information for all functions in the instrumented file and each function call those functions make. Instrumentation also identifies when a function calls into the operating system for operations like writing to a file.
Instrumentation reports use these four values to represent the total time spent in a function or source-code line:
Elapsed Inclusive - The total time spent running the function or source-code line.
Application Inclusive - The time spent running the function or source-code line. Calls to the operating system are excluded.
Elapsed Exclusive - The time spent running the function or source-code line. Calls to other functions are excluded.
Application Exclusive - The time spent running the function or source-code line. Calls to the operating system or other functions are excluded.
You can also collect both CPU and software-performance counters by using the instrumentation method.
Understand instrumentation data values
Collect detailed timing data by using instrumentation
Instrumentation method data views
Concurrency
Concurrency profiling collects information about multithreaded apps. Resource-contention profiling collects detailed call-stack information whenever competing threads wait for access to a shared resource. Concurrency visualization also collects more general information about how your multithreaded app interacts with:
- Itself.
- The hardware.
- The operating system.
- Other processes on the host computer.
Resource-contention reports display the total number of contentions. They also report the total time that modules, functions, source-code lines, and instructions waited for a resource. Timeline graphs show the contentions as they occurred.
The concurrency visualizer displays graphical information to help you locate:
Performance bottlenecks.
CPU underutilization.
Thread contention.
Thread migration.
Synchronization delays.
Areas of overlapped I/O.
When possible, the graphical output links to data from the call stack and source code. Concurrency visualization data can be collected only for command-line apps and Windows apps.
Understand resource contention data values
Collect thread and process concurrency data
Resource contention data views
.NET memory
The profiling method for .NET memory allocation interrupts the CPU at each allocation of a .NET Framework object in a profiled app. When the profiler also collects object-lifetime data, it interrupts the CPU after each .NET Framework garbage collection.
The profiler collects information about the type, size, and number of objects created in an allocation or destroyed in garbage collection.
When an allocation event occurs, the profiler collects additional information about the function call stack. The profiler increments exclusive allocation counts for the currently running function. It also increments inclusive counts for all calling functions on the call stack. .NET reports present the totals of these counts for the profiled types, modules, functions, source-code lines, and instructions.
When garbage collection occurs, the profiler collects data about the destroyed objects and about the objects in each garbage collection generation. At the end of the profiling run, the profiler records data about the objects that weren't explicitly destroyed. The Object Lifetime report displays the totals for each type allocated in the profiling run.
You can use .NET memory profiling in either sampling mode or instrumentation mode. The mode that you select doesn't affect the Allocation and Object Lifetime reports that are unique to .NET memory profiling.
When you run .NET memory profiling in sampling mode, the profiler uses memory allocation events as the interval. It also displays the total number of allocated objects and bytes as the inclusive and exclusive values in the reports.
When you run .NET memory profiling in instrumentation mode, the profiler collects detailed timing information together with the inclusive and exclusive allocation values.
Understand memory allocation and object-lifetime data values
Collect .NET memory allocation and lifetime data
Tier interaction
Tier-interaction profiling adds information to a profiling data file about synchronous ADO.NET calls between an ASP.NET page or other app and a SQL Server database. Data includes the number and time of calls and the maximum and minimum times. You can add tier-interaction data to profiling data that you collect with the sampling, instrumentation, .NET memory, or concurrency methods.
For information on tier-interaction data that is collected by profiling tools, see the following articles.