#2782

Gotchas: The Profiler Uses Processor Resources Too!

I was doing some work on the Parallel Programming with Microsoft .NET book yesterday. We’ve added some additional content to Appendix B to show some of the “visual patterns” that can tell you what’s wrong with your parallel code.

Here’s one of those patterns… The image on the left shows one of these patterns for an application with a load imbalance across the available cores. The vertical axis shows the number of cores being used, the horizontal axis shows time (click on the image to see a larger version). The green area shows the number of cores being used by my application.

As you can see I have a load imbalance problem. Some cores finish very quickly and are idle (grey on the graph) while others run for much longer. The overall time taken is entirely dependent on the longest running core.

And therein lies the problem. Why isn’t my application using all eight cores?! The eighth core is being used (indicated by the fact that it is colored yellow) but not by my application.

After some messing about investigation (and a hint from Steve Toub) I discovered that the profiler itself is the culprit! Because my application starts doing real work immediately and the profiler has some initial overhead the two compete for cores.

The solution is to add the following couple of lines to the start of the application being profiled.

Console.WriteLine("After the profiler has initialized press a key...");
Console.ReadKey();

Then you can start the profile session and after the profiler has started press a key in the application window to start the real work.

Now the profiler output is much more like what you’d expect. All eight cores are being used by my application. The graph timescale is different and I’ve cut off the initial startup section of the graph.

Note: If you’re really on the ball you might notice that the size green area has also changed between the two images. This is because in the process of tracking down this issue I modified the application to do more work.

You could also use Scenario Markers to to flag in the profiler exactly when your application started.

The source code for this example and others can be found on CodePlex along with a chapter describing some other common visual patterns that you can see using the profiler and how to use scenario markers.