Using the new Visual Studio Team System Profiler in the IDE - Part 2: Configure settings for a profiling run
Welcome back to my walkthrough of how to use the new profiler in Visual Studio Team System 2005. If you are unfamiliar with the new profiler, check out the first part of my walkthrough to get some basic info about the profiler. In the last section of this walkthrough, we looked at all the different access points where you can start up a new performance session from. In this section, we’re going to look at how to configure our performance session properties to customize the profiler for our specific application. We have tried to provide users with default settings that will work well for the broadest range of users. But, since each application is unique, you will almost always need to tweak some settings to get the best profiling data.
The first location to configure performance session properties is under the Tools->Options page in Visual Studio, shown in the picture below. This page lets you configure settings relating to all performance sessions, not just the currently active session. Pulling up the tools options menu, you can see the new Performance Tools tab below Environment, in the left hand menu bar. Under the Performance Tools tab there is a single page of options, shown below. The first option, a radio button to show time as CPU clock ticks or Milliseconds, is pretty self explanatory. The next option lets you select how many functions are shown in summary view. Summary view is the first view that you see when analyzing a performance run, it lists the top X functions in terms of total number of calls, total number of calls to function and all child functions and total time taken by function. I’ll go deeper into these statistics when I cover this view in a later walkthrough. For now, adjusting the number here adjusts the X in the summary view, so you can see more or fewer function in that view. The last option is serialize symbols, this option packs symbols in with your .VSP files so that you can copy them and read them on different systems without chasing down symbols files. .VSP files are the files that are generated with each run of the profiler, they will be discussed more in the next walkthrough.
The next spot to adjust performance session settings is in the properties page for the performance session, shown below. When you create a performance session, there is a new window opened called Performance Explorer. This window is for managing all of your performance sessions and .VSP files (and it’s the topic of my next walkthrough). To adjust the properties for a specific performance session, right click on a session (top level item in the view) and select properties from the menu. There are eight different property pages for a performance session, starting with the General page.
The first selection on the General page, is to select either sampling or instrumentation mode for profiling. If you want a brief rundown of sampling versus instrumentation, check part one of my walkthrough. The next option is for setting .NET memory allocation profiling and .NET object lifetime profiling. If you are profiling a .NET application, then these options can come in very handy. Enabling allocation information will tell you how many instances of objects were allocated, and enabling lifetime allocation information will tell you how long the profiled program held on to objects. With any garbage collection language this kind of knowledge is valuable in diagnosing performance issues, as large objects may be kept in memory for much longer then you had anticipated. The last section on this page contains options for the .VSP files that you will create each profiling run. You can choose the location to place the files, and you can choose to append a timestamp to the files.
The next properties page is the Launch page. The launch page simply has a list of all the binary targets for profiling. By checking the boxes you can select which binaries will be automatically launched when you start up your performance session. Also, you can arrange the binaries to get a specific launch order, if that is needed.
After the Launch page is the Sampling page. When profiling in sampling mode, the profilers stops execution to report where it is every X number of Ys. This page lets you set up what X and Y are. The default setting is to take a sample every 10 million clock cycles, a setting that provides a good baseline for many different profiling cases. You can also set the profiler to sample on Page Faults, System Calls or on a specific Performance Counter. If you select Performance Counter, then the list box in the middle lists all the different performance counters that you can use, such as mis-predicted branches or L2 cache misses.
The next five property pages all relate to the instrumentation mode of the profiler. In instrumentation mode, we insert code into the actual executables, so we can collect data for every function call and event that we hit. Understandably, this can generate a massive amount of data very, very quickly. That is why it is best to start out using the sampling mode to isolate performance issues. The first property page dealing with instrumentation options is the Binary page. This page lets you specify a specific location to place executables that have been instrumented. By default, we just instrument them in place while saving the original file with a .orig tag in the file name. The next page is the Instrumentation page, this page lets you specify custom pre and post-intrumentation steps to run, like pre and post-build events in the build system. After the Instrumentation page, is the Advanced page, which lets you pass in additional advanced options to the instrumentation engine. Next up is the Counters Page, it looks similar to the counters section in the Sampling page, and it lets you monitor specific performance counters to see when and where specific events are occurring.
The final properties page (I though we’d never get here!) is the Events page. When in instrumentation mode, we can record every time a specific ETW event is hit. ETW is a new performance logging feature, that can provide you with tons of different events from Windows, .NET runtime, ASP.net and IIS. For a good intro to ETW events check Matt Pietrek or MSDN. ETW events can be very useful, but they are also very noisy, so don’t just select them all and run profiling, you’ll get far more info then you bargained for.
That wraps up Part 2 of my walkthrough of using the profiler with Visual Studio Team System 2005. In the next section I’ll hit you up with some dirt on the Performance Explorer window and then I’ll move into covering the different analysis views.