Using the new Visual Studio Team System Profiler in the IDE - Part 1: Starting a new performance session
When I started working at Microsoft this past June, I was excited about two main aspects of my job. First off, I was going to work with developer tools. It’s a truly great thing to be able to work with and to improve a product that you yourself rely on to complete your job. And the second thing I was excited about, was that I get to work with the connection between my team’s profiler and the IDE and between our profiler and the end user. When you are consider the massive amounts of data that our profiler produces, you see the issues with turning that raw data into a 2D collection of pixels that will allow a developer or tester to isolate performance issues in their code. It’s a tricky problem to work with, but I find it fascinating.
If you are not familiar with the new profiler I’ll try to catch you up fast. Our team is focused on helping developers find and fix performance issues in their code. To accomplish this, we are integrating a profiler that performs both instrumentation profiling and sampling profiling into Visual Studio. This profiler is a part of the upcoming Visual Studio Team System. A recent issue of MSDN the magazine has an article that does a good overview of the profiler and its role in Visual Studio.
With this bLog, Microsoft is kind enough to give me a soap box to talk about how our product integrates with the IDE and how programmers can best use the profiler’s views to diagnose performance problems. Of course, I’ll also be talking about the usual smatter of interesting tech news, after all…it just wouldn’t be a bLog without that! However, my goal with this bLog is to keep up a solid stream of interesting posts about our profiler and working at Microsoft.
And in that vein, I’m starting out with a multi-part walkthrough on the profiler’s integration with the IDE and how to best use the various analysis views of the profiler. This week’s goal is to show all the various spots where you can launch the profiler in the IDE and how to configure your launch settings. Now I know that lots of power users are not fans of IDEs in general, and would prefer to deal with our profiler on a command line basis and to do their own custom analysis on the data. But since I work with the IDE, and happen to like it quite a bit, that’s what I’ll be covering here. Plus I'm hoping that this will help out users who want to take a quick and easy look at our tool and what it has to offer.
Whenever adding a new feature, discoverability is a big issue. We want people who didn’t know about the profiler on purchasing Visual Studio Team System to find it and start using it. So we created several different ways to add a new performance session to the current solution. The first option is through the Tools->Performance Tools menu option. From this menu you have two choices, 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. In the Add New Item dialog there is now a tab for performance under the general tab. Clicking on this tab will give you the same options as before: either create a new blank performance session, or start up the performance session wizard.
One of the key features of Visual Studio Team System is integration between all the features: source control, project management, testing and performance. So the final way to create a new performance session is through integration with the test results view. A unit test may have a wall time check associated with them, so if you add code that makes the test run too long, then the test will fail. A common way to investigate why the code took so long is to use a performance session. So if you right click on the finished test run, you can select Create Performance Session from the menu. This 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 is already 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 pages to fill out. The first page in the wizard guides you in selecting the target for your performance session. The options for selection are any projects in the current solutions, an .EXE, a .DLL or an ASP.net web application.
If you select a project in the current solution you will proceed straight to the performance session type page (shown below). If you selected an .EXE, you will be asked for the path to the file and for the working directory and for any command line arguments. For a .DLL, you have the same options as for an .EXE, but you also have to specify the path to an .EXE file that utilizes the selected .DLL. And for ASP.net you are asked for the local URL of the ASP.net app that you want to profile. The final screen in the wizard is the same for all of the above options. This screen asks you to pick either sampling or instrumentation profiling to profile your app.
I’m not going to go too in depth into the differences between sampling and instrumentation in this walkthrough. But in general, the best way to profile is to start with sampling mode to isolate “hot spots” in your code where there are performance issues. Then use instrumentation to instrument just the binaries with performance issues and run more focused, shorter scenarios while profiling. This is due to instrumentation producing a large volume of data, if you just start out with instrumenting everything and running a long 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 them, you can selected the method that works best for your project. After finishing the wizard you will now have a Performance Explorer window with a new performance session to launch in it.
In the next walkthrough I will look at configuring the setting for a performance session in more depth. Then we'll move on to looking at the various views we provide to help analyze the performance data.
Comments
Anonymous
February 09, 2005
Heard VS 2005 wont ship til later in the year. when?Anonymous
February 15, 2005
what's with the captial L?Anonymous
February 15, 2005
Hmmmm, well I saw blog spelled bLog on my boss's blog. And personally, I like the spelling a little better since puts a little more emphasis on the "log" part of it. Plus it adds some visual interest.Anonymous
April 01, 2005
Link: Using the new Visual Studio Team System Profiler in the IDE - Part 1: Starting a new performance session. Not that I needed more reasons to move to VS 2005 when available but here is another nice feature.Anonymous
June 09, 2005
I’ve pulled together all of the technical articles and walkthroughs from the various team member blogs...Anonymous
October 13, 2006
A little known feature of VSTS Team Developer is the ability to use the run-time analysis of the ProfilerAnonymous
June 21, 2007
I found Ian, a Developer onAnonymous
October 01, 2007
Following up on that last post about using the Queue data structure for FIFO operations, I thought it would be useful to look at a few things to consider before blindly using this classic structure....Anonymous
May 30, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=2611Anonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=20247Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=15544