VS2010 Performance Profiler

The Perf Profiler came out first in VS2005 and was (somewhat) enhanced in 2008. I’d happy to say that, despite the odd bug, VS2010 continues to nick good features from Ants Profiler and bundles them directly into VS (Premium or Ultimate edition only, though).

There are some good articles on MSDN describing it all in detail so I won’t go into everything in it, but will just outline some of the newer / improved features…

I’ve written some noddy code which continually appends a string to an existing string:

private const int ITERATION_LIMIT = 15000;
const string STRING_TO_USE = "Isaac loves Tottenham!";

static void Main (string[] args)
    string test = STRING_TO_USE;

    var stopwatch = Stopwatch.StartNew();
    for (int i = 0; i < ITERATION_LIMIT; i++)
        const string ELAPSED_TEXT = "{0:N2} seconds: Done {1} iterations…";
        if (i % 1000 == 0)
            Console.WriteLine(ELAPSED_TEXT, stopwatch.Elapsed.TotalSeconds, i);
        test = test + STRING_TO_USE;
    Console.WriteLine("All done, took {0} seconds", stopwatch.Elapsed.TotalSeconds);

Obviously due to the immutable nature of .NET strings, this is “bad code”. Running it with the profiler can help to identity such incompetence Smile

The Basics

Once you’ve profiled a run of your application, you first get a summary page showing you high level details of the profile: –


You can see that Concat (which is what gets called with you + two strings together) accounts for 99.91% of our work. You can drill into the view to get a sort of “visual call stack” which shows the calling method and the called methods within; you can double click either side to drill in or out further, to either the top or bottom of the stack:


Even better, you get a code view alongside this, with associated RAG highlighting, that updates as you go:


Nice. Obviously, in this example using a StringBuilder will give much better performance (in the region of 700-800x…).

Profiling Types

Notice, though, how only the String.Concat calls are identified in the function body, and not the calls to Stopwatch or Console.WriteLine etc.. That’s because I used CPU Sampling for the Profiler. If you use Instrumentation instead, you get much more detailed profiling results (I believe at the cost of performance during the Profiling):


You can also do a memory trace to see what’s eating up memory: –


That’s almost 5GB of memory allocated (and de-allocated) for those 15,000 strings!! Using a StringBuilder pushes it down to around a mere 600K. You can also compare two profile runs side-by-side to see the differences between them – neat.


VS2010’s profiler appears more usable than the 2008 one. The visual call stack is a nice feature and an easy way to dig into code without using a tree-style hierarchy. The addition of an ANTs-style visual graph plus better code visualisation as well as features like support for ADO .NET connections (not tested by myself, though) makes this well worth looking at the next time you need to fix a performance bottleneck.


2 thoughts on “VS2010 Performance Profiler

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s