55.4. Profiling Tools
Profiling tools will allow you to detect and correct performance and memory issues in your projects. The Profiler has two ways of getting its information. Sampling will periodically interrupt the application to capture its current state, and instrumentation will insert additional lines of codes to the selected assemblies. Instrumentation is more accurate but has more overhead than sampling.
The easiest way to start is by launching the Performance wizard from the Analyze menu. You need to select a project, executable, DLL, or web site to profile. Next you select the profiling type (sampling or instrumentation); you can start with sampling and change it later if you need to get more accurate results on a particular area. With that information, the Profiler wizard creates a performance session and opens the Performance Explorer window. You could also create a blank session from the Performance Explorer or from a test in the Test Results window.
In the Performance Explorer (Figure 55-3) you can change between instrumentation and sampling. Using the combo box, you could start the wizard again or manually create a new performance session. You could add targets to the performance session. Although you can instrument or sample a DLL, you need a point of entry for your application to run when you start the session, so be sure to include an executable, web site, or test as target.
Figure 55.3. Figure 55-3
55.4.1. Configuring Profiler Sessions
To configure your session, simply right-click and select Properties. In the General section you can change between sampling and instrumentation (Figure 55-4), and choose if you want to activate .NET memory profiling collection, the output for the reports, and the report names.
Figure 55.4. Figure 55-4
In the Sampling section you can select when to take samples; by default this is set to 10,000,000 clock cycles. Depending on what you want to track, you can change the sample event to page faults, system calls, or a particular performance counter.
The Instrumentation section is used to specify pre- and post-instrument events, for example to sign an assembly with a strong name. These settings are set on a per-target basis. The last section in the property page, Advanced, is also used when instrumentation is selected, and there you can specify additional command arguments. To see a list of available options, search for VSInstr on MSDN. VSInstr is the tool used to instrument binaries.
The remaining sections are used to specify the collection of different counters or events. CPU Counters will let you capture additional low-level information and will be displayed as extra columns in the different report views. These are only available for instrumentation. The Windows Counters are system performance counters and you will be able to see the results in the Marks report view. The Windows Events section will let you specify event trace providers. To see the information on Windows events you would need to manually get a text report using the following command:
Vsperfreport c:<path>ReportName.vsp /calltrace /output:c:<path>
55.4.2. Reports
Once you are all set, you can start the application, test, or web site from the Performance Explorer. It will run as usual, but will be collecting data. Once your application terminates, a report will be generated. Table 55-1 shows a description of some of the report views.
| Summary | Shows function information. Sampling it will show functions causing the most work and functions with the most individual work. With instrumentation it will show the most called functions with the most individual work and functions taking the longest. From here you can navigate to the Functions view. If "Collect .NET object allocation information" is selected as shown in Figure 55-4, it will show functions allocating the most memory and types with the most memory allocated and most instances. |
| Call Tree | Contains a hierarchy of the functions called. The Call Tree has a feature called Hot Spot that will point you to child functions taking most of the time. |
| Modules | Information about the module sampled or instrumented. |
| Caller/Callee | Will let you see which functions a particular function called and which functions called it. |
| Functions | Will present a list of all the functions sampled or instrumented. Double-clicking each function will let you navigate to the caller/callee window. |
| Allocations | You can see the number of instances and bytes allocated of a particular type. |
| Object Lifetime | Will show you how objects got cleaned on each generation. |
Additional reports can be generated using the command tool VSPerfReport. For more information, you can consult the MSDN documentation.
Allocation and Object Lifetime are only available if you select "Collect .NET object allocation information" and "Also collect .NET object lifetime information," respectively, in the session's property page. Some of the report views are different depending on the configuration. To see a description of a particular column, simply hover over its title. I suggest you go through the documentation on MSDN to get a thorough description on each report.
In all the views you can use the filter from the Toolbar to get to specific information. You can add or remove columns by right-clicking a header and sort using a particular column. Reports can be exported to either XML or CSV.