For those of you who are new to these walkthroughs, I am detailing how the new profiler in Visual Studio Team System 2005 works from within the IDE. If this is your first look at these walkthroughs, check out part one for my introduction and to learn how to start up a performance session. Then look at part two, where I talk about how to best configure your settings for a profiling run. In this installment, I’m going to take a quick look at the performance explorer, which is the central launching point for all your profiling runs.
If you follow the instructions in part one of my walkthrough, the performance explorer window should already by open. If it is not, you can open it under the “View” menu in visual studio, or you can create or open a new performance session file (.psess file extension) which will automatically open the window for you. In the performance explorer you will see nodes for all the current performance sessions (you can have multiple performance sessions in a solution). Each session has two folders under it, one for “Targets” and one for “Reports.” At the top of the performance explorer window, there are options to launch the performance wizard, to create a new performance session, to launch the currently active performance session, and a combo box to select either sampling mode or instrumentation. The difference between sampling and instrumentation modes is covered in both of my previous walkthroughs.
In sampling mode the “Targets” folder contains all the items that you want to collect profiling data from. If the binary icon has a green arrow on it, then that binary is one that you want to automatically launch when you start your profiling session. By right-clicking on a binary you can choose to specify if it is a launch binary or not. To add more binaries to a performance session, just right click on the “Targets” folder and select “Add Target Binary” (you can also add binaries from other projects in the solutions or from an ASP.net web application). In sampling mode, you automatically collect data from all the binaries that are running. But in instrumentation mode, you only collect data from the binaries that you choose to instrument. You can select what binaries to instrument by right-clicking on them in the performance explorer and selecting “Instrument.” Instrumented binaries have 1s and 0s on the binary icon to indicate that they are to be instrumented when the performance session is launched. When using instrumentation, you want to limit the number of instrumented binaries to keep from being overwhelmed with data. In the picture below, I’m profiling a small windows application that consumes a .dll file in instrumentation mode. The application (.exe) is selected as launch, so when I run the performance session it will be started. However, only the class library (.dll) is selected to be instrumented, so during the test run, the profiler will only collect data on that specific .dll not the entire application. This type of limiting is important in getting useful data from instrumentation profiling.
As you run your performance sessions, you will create .vsp report files that contain the data for the profiling runs. These reports show up under the “Reports” folder of the performance explorer. The default is that they are named after the solution, with a unique timestamp appended onto the end. By double clicking on any report file, you can open it for analysis in the IDE. Also, by right-clicking on the “Reports” folder you can choose to add any previously created report files to the current session.
As I mentioned before, you can have more then one performance session for any given solution. In the performance explorer below, I have both a sampling session and an instrumentation session open for my sample project. The session name that is bolded is the currently active session, which is that one that will be run when the “Launch” button is pressed. To set an inactive session as the current session, just right-click on its name and select “Set As Current Session.” Each session has its own “Reports” and “Targets” folder and separate session properties. As you can see, in each session the application must be specified as a launch target. You cannot start up a performance session if you do not have some executable selected to launch.
At this point in my walkthroughs, you should have a good grasp of how to setup a performance session for your application. The next step is to click that “Launch” button in the performance explorer to generate some report files. In my next walkthrough I’ll start to look at the various analysis views that the IDE provides to help find the performance problems that are plaguing you.