Profiling IO Bound applications with Visual Studio Team System – Part One
It just so happens (and I know that I’ve mentioned it here before) that the Visual Studio Team System Profiler has both sampling and instrumentation modes available for you to use. However, in most of my samples so far I’ve been using the sampling mode of the profiler to profile some small applications. And for almost all CPU bound applications the sampling mode is the mode to use as it collects much smaller data files as compared to instrumentation profiling. However, for diagnosing performance problems that are not CPU bound then you may only be able to track down the performance issue by using the instrumentation mode of the profiler. In this blog entry we will look at using the instrumentation mode of the profiler to track down an IO bound issue in a small sample application.
But before we get too deep into using the profiler to diagnose an IO Bound application we may want to better define exactly what “IO Bound” and “CPU Bound” mean.
· IO Bound – An IO bound application is an application where its speed is dependant on waiting for IO operations to complete. In other words, you are asking for data and moving it around more then you are actually computing things
· CPU Bound – A CPU bound application is an application where its speed is dependant on waiting for the CPU to process data. In this case you have the data, but you have to wait to perform calculations on it
There are other types of binding (such as memory bound) but we’re not going to look at those in this specific blog entry. In general, IO bound issues are caused by things such as moving data from your hard drive into memory in some inefficient fashion. This is opposed to things that are CPU bound where your time is spent waiting for the CPU to finish processing tasks.
In general we recommend that users start out by using the sampling mode of the profiler as it is lighter weight and collects smaller data files. One exception to this rule is IO bound applications. For IO bound issues sampling on CPU cycles (take a snapshot of program execution every X cycles) is not a good was to investigate. Since program execution is blocked on waiting for IO operations to complete you will end up seeing very high sample numbers in wait functions.
On the other hand, instrumentation mode will help to point you at the exact function that is taking all of the time as opposed to the wait function. It will help to keep you from being mislead by the time that is spent in those wait functions. Right now I’m working at cooking up some examples of IO Bound and Memory Bound applications. So as soon as those are up I’ll post some walkthroughs of profiling them with the Visual Studio Team System Profiler.