Visual Studio Profiler Team Blog : team system

Walkthroughs: Using VSTS Test and Profilers to Find Performance Issues

profiler — Wed, 15 Oct 2008 23:54:00 GMT

Tess Ferrandez recently wrote a couple of articles that extend her popular series of debugging labs to focus on measuring and improving performance.

In 'Using VSTS Test and Profilers to troubleshoot performance issues (low cpu hang)', Tess introduces a performance problem into an ASP.NET application and uses the Visual Studio Profiler with a Load Test to track down the problem.
In 'Using VSTS Test and Profilers to troubleshoot a High CPU in GC issue', Tess tracks down a string concatenation issue that is causing high CPU usage due to garbage collection.

The walkthroughs include sample code, lots of screenshots and analysis.

[Colin Thomsen]

Quick Tip: VS2008 - Compare Reports Quickly

profiler — Wed, 02 Jul 2008 20:00:00 GMT

While investigating a performance problem you may need to collect many Performance Reports and compare them. You can use the Performance Explorer to quickly compare two reports by:

Selecting two reports.
Right-clicking and choosing 'Compare Performance Reports...'

The oldest report will be used for the 'Baseline' report and the other report will be used for the 'Comparison' report, as shown below:

[Colin Thomsen]

What code path is allocating the most bytes for a type?

profiler — Sun, 15 Jun 2008 02:26:00 GMT

In Visual Studio 2008, we added the ability to quickly determine the most expensive call stack in your application. In profiler parlance, the “most expensive call stack” is known as the “hot path”. What do we mean by “expensive”? “Expensive” is whatever measure you want it to be: number of samples in a function, time spent in a function, or even number of bytes or allocations in a function.

If you profile the managed memory usage of your application (also available in VS2008), you will get a new view in your profiling report called the Allocation View:

For each managed type allocated in your application, this view will show you the call stack where each allocation took place as well as the number of bytes and instances allocated in each function.

You can explore these call trees as you do normally, including using hot path to find the expensive allocation paths through your code for a specific type. This is accessible through either the toolbar or the context menu by right-clicking on the function from where you want to start hot path:

In this example, we know we’re allocating about 741KB of memory for System.Drawing.Graphics objects. Using hot path, we can quickly determine that the majority (67%) of the bytes are being allocated in System.Drawing.Graphics.FromHwndInternal. Because we do not control this code, we can look up the stack until we see code that we can change: MainForm.SetCell. This would be a great place to begin investigation.

It’s important to note that the allocation hot path is not the single function allocating the most bytes in your application (you can use the Function View for that). Instead, it is the specific path through your code that is allocating the most bytes for a type.

[Chris Schmich]

Quick Tip: "Save Analyzed" for large VSP files

profiler — Sun, 18 May 2008 09:54:00 GMT

One cool new feature in the Visual Studio 2008 Profiler is the ability to take a large VSP file that has been analyzed once and save the report data into a VSPS file (Visual Studio Profiler Summary files). Saving the analyzed data has several major benefits:

The analyzed data is orders of magnitude smaller than the VSP file. We've seen 4GB trace VSPs get compressed into less than 100K VSPS files.
Because the data saved in the VSPS files has already been processed by our data analyzer, it will load up much faster.
Symbol data is automatically packed into the VSPS file.

VSPS files because of their small size, quick analysis, and saved symbols are perfect for use as saved baselines with the new performance comparison functionality in VS2008. A best practice is to regularly save off VSPS files for your performance scenarios so you can look for performance regressions from one milestone to the next.

This feature is not particularly discoverable. Here's a quick map of where to find it (highlighted in yellow):

One caveat: because the data has already been analyzed in the VSPS file, you can't use filters on VSPS files.

[Steve Carroll - scarroll]

Articles on new Visual Studio Team System 2008 profiler features

profiler — Fri, 19 Oct 2007 20:10:00 GMT

I’ve recently been working on a series of post on my blog about many of the cool new features that we are adding in Visual Studio Team System 2008 (codename Orcas). So I figured that I’d post a quick link here to all the articles that I’ve finished so far.

Collecting Performance Counter information with the Visual Studio Profiler

Pinpoint a performance issue using hotpath in Visual Studio 2008

The Visual Studio Profiler Data Collection Control Part 1: Excluding Application Startup Time

Comparing performance reports with the Visual Studio Team System Profiler

[ianhu]