Improve Code Performance with the VSTS Code Profiler, Page 2
The final screen of the wizard is simply a summary screen, and once the wizard has been completed, a performance session is added to the project. The performance session is displayed through the Performance Explorer window, and displays the profiling mode, the profiling targets, and the results of any profiling sessions that have been conducted. Starting a profiling session can be achieved by clicking the third button (the one with a green arrow) at the top of the Performance Explorer toolbar.
It also is possible to add new targets to a profiling session from the Performance Explorer Window, and this is particularly useful for a large project that typically will have many DLLs. Sampling profiling can be used to detect which DLL the performance problem is in, and instrumentation can be used to drill into the methods of the problem project. It is possible to turn profiling on and off for each target via a context menu. It would be usual to have sampling turned on for each target, but once instrumentation sampling was selected, it is advisable to reduce the number of targets it is applied too.
Figure 4: Performance Wizard.
Analyzing Performance Results
It is difficult to demonstrate the benefit of sampling profiling in a demonstration application that may only contain a couple of hundred lines of code, but for real-world applications that can contain dozens of DLLs and hundreds of thousands of lines of code, using sampling profiling to narrow down a performance problem is critical. Instrumentation sampling collects a huge amount of data, and it is easy to end up with a profile report spanning tens of gigabytes that is very slow to process both from a software and developer perspective.
Once a specific group of projects has been identified as the source of performance problems, instrumentation profiling makes tracking down the results relatively straightforward. The results of a profiling session, as shown in Figure 4, comprise information categorized in a number of different views accessible via a dropdown menu, as shown in Figure 5.
Figure 5: Performance Results.
For blatant performance problems, the Performance Summary Screen often can identify the performance-problem culprit with the % of time in method figures. For more subtle performance problems, switching to the other pages in the performance report will be required. The Call Tree View presents the call tree of an application along with the number of time a method has been called. There are also many other columns that can be added, including the ability to inspect the actual time spent in methods (both inclusive and exclusive timings) and function line number (for sampling profiling only). The other two views that are helpful for finding performance problems are the Caller/Callee View and the Functions view.
Managed Code Profiling
In addition to the native code profiling capabilities covered so far, the VSTS Code Profiler is equally capable profiling C#, Visual Basic.NET, and C++/CLI managed code. The basics of managed code profiling are the same as native code profiling, but there are a number of different options that deal with managed code-specific problems. The most significant difference is the ability to collect information about the allocation and lifetime of managed objects. As the lifetime of managed objects is controlled by the .NET garbage collector, diagnosing problems related to excessive memory consumption can be more difficult in .NET projects. Turning on the collection of .NET memory statistic is accomplished by bringing up the Properties of a Performance Session from the Performance Explorer window, and selecting the options shown in Figure 6.
Figure 6: Enabling Managed Memory Tracking.
Page 2 of 3