Team System

Simple Profiling with Team Developer

Team System Developer Edition (and, of course, Team Suite) includes integrated application profiling. Profiling is just a fancy way of saying "performance analysis".

If you've ever wondered..

1. What parts of my code are slow?
2. How much memory is my program using?

.. then profiling is for you.

Here's a little program I whipped up that concatenates strings two different ways. We'll try simple concatenation using the plus (+) operator, then try with a StringBuilder.

---

class Program
{
    private static string _text = "The quick brown fox jumps over the lazy dog ";
    private static int _iterations = 5000;

    static void Main(string[] args)
    {
        AddStringsConcat();
        AddStringsBuilder();
    }

    static string AddStringsConcat()
    {
        string s = "";
        for (int i = 0; i < _iterations; i++)
        {
            s = s + _text;
        }
        return s;
    }

    static string AddStringsBuilder()
    {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < _iterations; i++)
        {
            sb.Append(_text);
        }
        return sb.ToString();
    }
}

---

Okay, so this one is kind of er.. obvious, but it's a good test case for profiling.

Let's kick off the profiler via the Tools, Performance Tools, Performance Wizard menu. One of the first questions the Wizard asks is... Sampling or Instrumentation?



You almost always want to start with sampling. Instrumentation has an enormous memory and disk footprint. That said, if you are narrowly focusing on a specific bit of code, you definitely want instrumentation to isolate it.

That's the only question of consequence in the wizard. It's really short. Once you finish, you'll have a new performance project in the Performance Explorer pane on the left hand side of the IDE. Right click the project, then select "Launch" to run it:



The output is an enormously detailed multi-page report. However, the first page is a simple high level summary:



So it's pretty obvious where the problem is:

• We spent 96 percent of our execution time in the AddStringsConcat() function.
• We spent 42 percent of our execution time in the System.String.wstrcpy function.
  

Adding five thousand strings together with the plus operator is, apparently, a Really Bad Idea^tm. But wait-- it gets worse!

The default performance analysis only measures runtime. It doesn't include any information about memory footprint! Let's fix that. Right click the performance project and select Properties:



Now turn on memory profiling collection:



Click OK and re-run the performance analysis. Don't worry, our old results aren't overwritten -- a new report will be generated alongside the old one.

Here's the summary page for the new report:



Note that this is completely different than the previous summary-- it's all about memory now. And boy are we using a lot of it:

• System.String.Concat is using 995 kilobytes of memory
• We created 5,029 instances of System.String

That's pretty awful compared to the 1.4 kilobytes that the StringBuilder needed.

These high level summaries aren't just HTML, either. They're fully clickable for drill-down detail. For example, if I was curious about those 5,029 instances of System.String, I can double-click on it:



As expected, the vast majority of these allocations are a result of our incredibly naive string concatenation.