Profiling is the process of observing and recording metrics about the behavior of an application. Profilers are tools used to help identify application performance issues. Issues typically stem from code that performs slowly or inefficiently or code that causes excessive use of system memory. A profiler helps you to more easily identify these issues so they can be corrected.
Sometimes an application may be functionally correct and seem complete, but users quickly begin to complain that it seems "slow." Or perhaps you're only receiving complaints from one customer, who finds a particular feature takes "forever" to complete. Fortunately, Team System's profiling tools can help in these situations.
A common use of profiling is to identify hotspots, sections of code that execute frequently or for a long duration as an application runs. Identifying hotspots enables you to turn your attention to the code that will provide the largest benefit from optimization. For example, halving the execution time of a critical method that runs 20 percent of the time can improve your application's overall performance by 10 percent.
Most profiling tools fall into one (or both) of two types: sampling and instrumentation. A sampling profiler takes periodic snapshots, called samples, of a running application, recording the status of the application at each interval, including which line of code is executing. Sampling profilers typically do not modify the code of the system under test, favoring an outside-in perspective. Think of a sampling profiler as being like a sonar system. It periodically sends out sound waves to detect information, collecting data about how the sound refracts. From that data, the system displays the locations of detected objects.
The other type, an instrumentation profiler, takes a more invasive approach. Before running analysis, the profiler adds tracing markers, sometimes called probes, at the start and end of each function. This process is called instrumenting an application. Instrumentation can be performed in source code or, in the case of Team System, by directly modifying an existing assembly. When the profiler is run, those probes are activated as the program execution flows in and out of instrumented functions. The profiler records data about the application and which probes were hit during execution, generating a comprehensive summary of what the program did. Think of an instrumentation profiler as the traffic data recorders you sometimes see while driving. The tubes lie across the road and record whenever a vehicle passes over. By collecting the results from a variety of locations over time, an approximation of traffic flow can be inferred.
A key difference between sampling and instrumentation is that sampling profilers will observe your applications while running any code, including calls to external libraries (such as the .NET Framework). Instrumentation profilers gather data only for the code that you have specifically instrumented.
Team Developer offers powerful profiling tools that you can use to analyze and improve your applications. The profiling tools offer both sampling and instrumented approaches. Like many Team System features, profiling is fully integrated with the Visual Studio IDE and other Team System features, such as work item tracking, the build system, version control check-in policies, and more.
The profiling tools in Team System can be used with both managed and unmanaged applications, but the object allocation tracking features only work when profiling managed code.
The profiling tools in Team System are based upon two tools that have been used for years internally at Microsoft. The sampling system is based on the Call Attributed Provider (CAP) tool, and the instrumentation system is based on the Low-Overhead Profiler (LOP) tool. Of course, Microsoft did not simply repackage existing internal tools and call it a day. They invested considerable development effort to add new capabilities and to fully integrate them with other Team System features.