Analyzing a performance report in Visual Studio Team System 2005 Part 4: Fixing the performance issue and analyzing the results.

The last three installments of this walkthrough have helped show you how to use the new profiler in Visual Studio Team System 2005. In this final section, I’ll show how to jump into the code to fix a performance issue, then how to run the profiler again to see if we improved the performance with our code fixes. In these walkthroughs, we’ve been using an example program that I downloaded from Got Dot Net. To better follow along with the analysis that we’ve already done, you should check out the first three walkthroughs here, here and here.

            The summary of our initial analysis is that we see two possible performance issues. I’ve placed a picture below from the summary view of our earlier analysis. First off, we see that most of our time is taken up in the Rational.reduce function (check the functions with most individual work section). And secondly, we see that Array.GetUpperBound is being called a very large number of times. In addition, in the caller / callee view we noted that Array.GetUpperBound was always being called from Rational.reduce, so perhaps there was a link between the two issues.

            Now we are at the point in the analysis where we know enough to jump into the source code to look around for our issue. From any view, just right click on the Rational.reduce function and select “View Source” to jump straight to the correct point in the source file. Pictured below on the left is where Array.GetUpperBound was being called in Rational.reduce. By being called in for loop it must be called every single time the loop runs! Let’s move the call to GetUpperBound outside of the loop, as pictured below on the right.

            After making this change, I rebuild the code and ran another performance session in instrumentation mode. Pictured below is the summary view from the new run with the improved code.

            As you can see from comparing this to the original summary view above, we made a *major* performance improvement to Rational.reduce. The time spent in that function dropped from 164 milliseconds to 70 milliseconds. And GetUpperBound is no longer on the top three functions in terms of number of calls or in the terms of most individual work. You’ll notice that the function Forms.Application.Run took a little longer with the new code. That is only due to the fact that I was a little slow in closing the application window on the second run-through of my scenario.

            So in summary, I was able to download a random application off of the internet, find a performance issue in it, change the code to fix the issue and then figure out how much we improved the code in just about half an hour of work. Also, the issue that I found was a real issue, not a fake performance blip that I seeded the program with. That’s the great thing about the profiler, it makes it easier to find performance issues in code that you did not write yourself and are not familiar with.