The Visual Studio Team System (VSTS) Profiler ships as part of the Developer Edition product, and is now in its second version with the release of VSTS Team System 2008. The initial release of the VSTS Profiler was the first profiler that shipped as part of the Visual Studio/VSTS product family since the Visual C++ 6 profiler, and although the profiler had good fundamentals, the VSTS 2005 release was very much a Version 1 product, and could be difficult to use for some profiling tasks. With VSTS 2008, the Profiler is much improved, and well worth considering as the first-choice profiler in a developer’s toolkit.
Many commercial profilers operate in a single mode in which the amount of time spent executing each line of code within an application is measured. The problem with this approach is that the measurement can have a very large performance impact on the application being profiled, and wading through the huge amount of data collected can be an overwhelming task. The VSTS profiler takes a different approach, and there are two distinct profiling modes available: sampling and instrumentation. During sampling profiling, the execution of the application is periodically paused and the functions that are executing are recorded. Sampling profiling has a low impact, and allows the area of an application that is causing the performance problem to be identified. Once a specific binary with performance problems has been identified, the sampling mode can be switch to instrumentation, in which specific binaries are re-compiled with instrumentation probes inserted; this allows every execution of a piece of code to be recorded and reported on.
Getting Stated with Profiling
Starting a profiling session is quite simple: With VSTS Developer installed, a menu item called Analyze will be available as shown in Figure 1, and the Launch Performance Wizard… guides the user through setting up a profiling session.
Figure 1: Launching the Performance Wizard.
The first screen of the performance wizard prompts the user to select the application to profile. In addition to a list of the projects in the current solution, it is possible to select an executable, a DLL, or an ASP.NET application to profile, as shown in Figure 2.
Figure 2: Profiling Target.
The second screen of the wizard allows the profiling mode to be specified, and provides a reasonably detailed description of the two modes.
Figure 3: Profiling Mode.
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.