Guidelines for Using Performance Tools
The following list provides several techniques for detecting performance problems.
Required
Determine a sample event and a sample interval.
Before profiling the application, determine the correct sample event to use for collecting the data.
The performance tools provide four types of sample events:
Clock cycles - for CPU bound problems
Page faults - for memory related problems
System calls - for I/O related problems
Performance counters - for low-level performance problems
After choosing sample event, determine appropriate sample interval for your application. The interval you choose determines how frequently the performance tools will interrupt the execution of your application to collect performance data.
Sample the application.
Start by sampling the application to narrow the sections of the application that cause performance problems. Sampling is an important step, especially if you do not know which sections of the application are causing performance bottlenecks. During sampling the application is only interrupted periodically to collect data; therefore, it is possible that performance data might not be collected for certain areas of the application. To increase the possibility of capturing relevant data, you might choose to exercise the same sequence of steps more than once.
Important Only running threads are sampled. Data is not collected for threads blocked waiting for I/O, mutex, semaphore, or event. Suspended threads do not consume CPU and are not sampled.
Use instrumentation carefully.
Instrumentation is not a substitute for sampling. Use instrumentation to gather performance data for the specific sections of the application that were identified as performance bottlenecks during the sampling phase. During instrumentation, a lot more data is collected and it should only be used after you know the sections of the application that are the cause of the performance problems.
Important Instrumentation might be a better choice if your code runs in a larger framework, such as an ASP.NET Web site or an add-in for the IDE. Because your code is running in the context of a larger framework, it might be infrequently sampled compared to the rest of the framework and prevent you from identifying performance issues in your code. Use sampling in this case only to identify issues of interaction with the larger framework.
Sign the assembly with a strong name.
If you instrument a signed assembly, you must re-sign the assembly before it can be used.
Avoid
Shipping instrumented files
You must instrument assemblies and binary files to be able to perform instrumented profiling and measure the code coverage achieved when they are tested. But after a file has been instrumented, it remains in the instrumented state. This is important to consider because shipping files that have been instrumented can expose your organization to a security risk. This is because files that have been instrumented have an increased vulnerability to being reverse-engineered. However, before you ship an assembly or binary file, you can test it to determine whether it has been instrumented. Run it on a computer that does not have VSPerf80.DLL or VSCover80.DLL installed; VSPerf80.DLL is included in the installation of Visual Studio performance tools. If the file you are testing has been instrumented, it will not work on that computer.
Treating performance counters as PerfMon counters.
Performance counters are not the same as PerfMon counters. Performance counters are on-chip counters used to investigate low-level performance issues. For information about performance counters for a specific processor, refer to the hardware manual provided by the manufacturer.
Recommended
Use a release build with symbolic (debug) information.
Debug and release builds can exhibit very different performance profiles.
Use product symbols.
For information about symbols and symbol server, see How to: Specify a Symbol Path and How to: Use Symbol Servers.
Choose .NET object allocation and lifetime information.
Include object allocation and lifetime data to detect memory related problem in managed applications.
Choose event trace providers.
Determine the event trace providers that are appropriate for your application. The data collected during profiling can only be viewed by using the /calltrace option of the VSPerfReport command-line tool.
See Also
Concepts
Understanding Web Tests
Understanding Load Tests