TN_1208: Creating a new profiling session in Visual Studio Team System

Ian Huff, Software Design Engineer
Microsoft Corporation

One of the great new tools included with Visual Studio Team System Developer edition is the new performance profiler. This tool will help you to diagnose various performance issues that might be afflicting your native, managed or ASP.NET application. The profiler can be fully command line driven for automation, but we have also taken the time to tightly integrate it with the Visual Studio IDE. This TechNote will take a look at the various places where you can start up a new performance session from the IDE, and take a look at the performance session wizard.

Whenever you add a new feature to an already rich IDE, discoverability is a big issue. The profiler doesn’t help people if they can’t locate it, so we created several different ways to add a new performance session to the current solution. The first option is to go through the Tools->Performance Tools menu option. From this menu, you have two choices; you can either start up a new blank performance session, or start the performance session setup wizard (which I will discuss later).

The next access point for a new performance session is by adding a new item to a solution. Right click the solution and bring up the Add New Item dialog (shown below). In the Add New Item dialog there is now a tab for performance under the general tab. Click on the performance tab and you will get the same options as before: you can either create a new blank performance session, or you can start up the performance session wizard.

One of the key features of Visual Studio Team System is integration between all of the new features: source control, project management, testing and performance. So the final way to create a new performance session is through integration with the unit testing framework. When you run a Visual Studio Team System unit test it may have a wall clock time check associated with it, so if you added code that makes the test run too long, then the test will fail. After the test fails, a common next step would be to use the profiler to examine why the code you added slowed the test down so much. So if you right click on the finished test run in the Test Run Results window (shown below) you can select “Create Performance Session” from the menu. Selecting Create Performance Session takes you to the performance wizard to create a performance session for the unit test in question. This wizard is slightly different from the normal performance wizard, as the unit test has been pre-selected as the performance target.

The last thing that I want to cover is the new performance session wizard. A lot of users don’t like the concept of wizards, but give this one a try; it will save you from having to muck about too much in the performance session property pages, and it only has a few well-explained pages to fill out. If you are running the profiler for the first time the wizard can be especially useful in making sure that you have the correct targets selected to profile. The first page in the performance session wizard guides you in selecting the targets for your performance session. The options for selection are any projects in the currently open solutions, an executable file, a .DLL file or an ASP.NET web application.

If you select a project in the current solution you will proceed straight to the profiling method selection screen seen below. If you selected to profile an executable, you will move to a page where you call fill out the path to the executable file and specify the working directory and any command line arguments to run with the executable. If you selected to profile a .DLL file, you will have the same options as for an executable, but you also have to specify the path to an executable file that utilizes the selected .DLL. And finally, if you select to profile an ASP.NET application, you will be asked for the local URL of the ASP.NET app that you want to profile. For all of the above choice you will end up at the profiling method selection page of the wizard. This screen asks you to pick either sampling profiling or instrumentation profiling to profile your app.

I’m not going to go too in depth into the differences between sampling profiling and instrumentation profiling in this TechNote. In a nutshell, sampling profiling captures program state by sampling at specified intervals (such as clock cycles or page faults) and instrumentation profiling inserts probes into your code to catch every single function call made by your program. In general, the best way to profile is to start out with sampling mode to isolate performance “hot spots” in your code where there are performance issues. Then, if needed, you can use instrumentation profiling to instrument just the binaries with performance issues and run shorter, more focused profiling scenarios. This is due to instrumentation profiling producing a large volume of data; if you just start out by just instrumenting everything in your project and running a long profiling scenario, then the size of your profiling (.VSP) files with get out of hand very quickly. By giving you the choice of which to use, and allowing you to switch easily between the two profiling methods, you can selected the method that works best for your specific profiling scenario. After finishing the wizard you will now have a Performance Explorer window open with a new performance session correctly configured to launch in it.