A while ago I started using the Performance Tools that came bundled with Visual Studio 2005 Team Suite to analyse my code. There are two analysis methods: sampling and instrumentation. Although instrumentation has a higher overhead, it can reveal in greater detail exactly what your program is doing. In order for instrumentation to proceed, one must link with the /PROFILE switch and then use VSInstr to insert counters into one’s code. To cut down the cruft collected during a profiling session, one can use the VSInstr switches to dictate exactly which functions should be instrumented and/or use the VSPerf API to command the profiling engine to start/stop/suspend/resume/mark data collection during a run.
One fatal flaw of the Performance Explorer in the 2005 IDE was that one couldn’t start a program with data collection in the stopped state. It would always start collecting data from the very beginning of execution. Visual Studio 2008 includes a command to “Launch with Profiling Paused”, which is a great way to only start profiling when you need to (e.g. via StartProfile or VSInstr /STARTONLY).
Alas, there is still a bug in the Performance Explorer (or, rather, in its build system). If one selects, through the Binary properties of a performance session, to ‘relocate instrumented binaries’, and then proceeds to set ‘additional instrumentation options’ in the Advanced section, the IDE will complain when attempting to start a new profiling session and print this error message in the Output window: “Object reference not set to an instance of an object.”. This is highly annoying because it is helpful to put the instrumented binaries elsewhere (not where the original build outputs reside) AND add specific command line options, such as /VERBOSE and /CONTROL (in conjunction with the others).
I don’t know how to work around this bug; I had hoped it was fixed in 2008, but apparently not. The easiest thing is to not relocate the instrumented binaries. Perhaps one can add another build configuration that includes the /PROFILE linker option and uses its own folder as the build output destination where the binaries can be instrumented in-place.
Here are some helpful resources about using the Performance Tools:
http://blogs.msdn.com/angryrichard/archive/2005/01/16/354194.aspx
http://blogs.msdn.com/scarroll/archive/2005/04/13/407981.aspx
http://blogs.msdn.com/ianhu/archive/2005/06/09/427327.aspx
If you liked my post, feel free to subscribe to my rss feeds
BlogoSquare