Before Visual Studio 2010, in order to attach the profiler to a managed application, certain environment variables had to be set using vsperfclrenv.cmd. An example profiling session might look like this:
If the environment variables were not correctly set, when attempting to attach you would see this message:
The profiling environment for ConsoleApplication2 is not set up correctly. Use vsperfclrenv.cmd to setup environment variables. Continue anyway?
The generated report would typically look something like the report below. The warning at the bottom of the page indicates the problem and the report itself would typically not be useful since no managed modules or functions would be resolved correctly.
Report with 'CLRStubOrUnknownAddress and Unknown Frame(s) and the warning ‘It appears that the file was collected without properly setting the environment variables with VSPerfCLREnv.cmd. Symbols for managed binaries may not resolve’.
Fortunately the Common Language Runtime (CLR) team provided us with a new capability to attach to an already running managed application without setting any environment variables. For more detailed information take a look at David Broman’s post.
The new procedure for attaching the profiler to a managed application in Visual Studio 2010 goes like this:
If you want to diagnose any issues with attach, the CLR V4 runtime provides diagnostic information via the Event Log (view with Event Viewer) and the profiler also displays information there:
Event Log: ‘Loading profiler. Running CLR: v4.0.21202. Using ‘Profile First’ strategy’
There are two .NET Runtime messages regarding the attach, the first indicating that an attach was requested and the second that the attach succeeded. The VSPERF message describes which CLR is being profiled.
This year if you didn't get a chance to go to the Professional Developer's Conference (PDC), there is still a wealth of information available to you. The most valuable resource I think are the videos of all the PDC sessions. Here are a few of the sessions that I've viewed and found most interesting:
If you'd like to try some of the Visual Studio 2010 features for yourself, you can download the newest CTP here.
This week Microsoft is starting to talk about Visual Studio 2010. One of the best resources I've seen has a bunch of videos from various Microsoft folks about some of the new features and what the high-level goals of the next release of Visual Studio are. Take a look at the Channel 9 site.
There isn't much about profiling just yet, although some of the other features being developed by the diagnostics team including 'Eliminate No-Repro Bugs' and 'Test Impact Analysis' are covered. For more details about those features, you may also want to keep an eye on John's blog.
We'll also start talking about some of our new profiling features on the main profiler blog. If you're going to PDC, be sure to check out my boss Steve Carroll's (and Ed's) session:
You'll get to see how some of our new profiler features make finding and solving performance problems easier.
The Visual Studio Profiler has many properties and options and this tip shows you where to find most of them. Future posts may cover some of the specific properties in more detail.
Performance Session Properties (and Options):
Properties for Performance1 are shown below. There are different categories of properties on the left (e.g. General, Launch, Sampling, …).
Adjust the properties for the Performance Target as required. These properties do not often need to be changed, with the possible exception of the Instrumentation property ‘Exclude small functions from instrumentation’.
Tools –> Options –> Performance Tools:
Some global options can be configured using the Visual Studio Options dialog, which is accessed via:
Tools –> Options –> Performance Tools
That’s all the properties I can think of but I’m probably missing some still. Probably the most important aspect to this tip is to emphasize that right-clicking with the mouse is often the way to access important contextual information.
If you have a solution that contains multiple projects it is important to know what the 'Targets' group in the Performance Explorer is used for. The PeopleTrax solution shown on the right has 4 projects, with 3 of them compiling to managed DLLs and 1 compiling to an executable.
After running the Performance Wizard to create a Performance Session the Performance Explorer contains a single target as shown below.
Only the project that compiles to an executable is listed in the 'Targets' folder (for other project types like websites it would include the default launch project). What about the other 3 projects? As this tip explains, it depends upon the type of profiling you wish to do.
With sampling there is no need to add the additional projects to your targets list. We do not modify assemblies when sampling and we will automatically attempt to collect data for any assemblies loaded by the PeopleTrax target. The only exception to this requirement is if you wish to collect data for multi-process scenarios and therefore need to launch multiple targets.
For instrumentation, if you wish to collect data for the additional projects they should be added to your targets list as follows:
The selected projects will now be modified (instrumented) when you start profiling. You can selectively disable instrumentation for certain projects by right-clicking on the target and unchecking the 'Instrument' option.
Instrumentation properties for a specific target.
While investigating a performance problem you may need to collect many Performance Reports and compare them. You can use the Performance Explorer to quickly compare two reports by:
The oldest report will be used for the 'Baseline' report and the other report will be used for the 'Comparison' report, as shown below:
Quite a few people at Tech-Ed wanted to know more about the various components of Visual Studio Team System (which we sometimes refer to as SKUs). For example, how does Team Foundation Server (TFS) fit in with the client SKUs? What are the differences between Visual Studio Team System Development Edition and Visual Studio Team System Test Edition? What is Visual Studio Team Suite?
These are very valid questions when you're considering which SKU to buy and since I'm not a sales or marketing guy I'll defer to some nice diagrams and comparisons already available on the web:
While we were demoing at Tech-Ed we were giving out trial versions of Visual Studio 2008 Team Suite, with some detailed tutorials (called Hands-On Labs) and they were very popular. If you'd like to try out the Virtual PC Image as well, download it here.
Some of my colleagues at Microsoft were interviewed for a panel discussion about various aspects of Team System which is worth watching to see where Team System is heading (Visual Studio Team System Panel - Meet the Team).
I also managed to catch a few sessions at Tech-Ed and one of the more interesting talks was about Visual Studio 2008 Tip of Day. Each day for more than 230 days now, Sara Ford has been posting blog entries with tips for Visual Studio.
UPDATE: I forgot to mention an interesting series on Channel 9 that I found out about while at Tech Ed. This Week On Channel 9 covers some of the highlights from Channel 9 blogs, articles and videos. The focus is on the developer, which works well for me. The current episode talks about PDC, Pex, Build Bunnies, UltraCam and the Live Agents SDK.
Last year my boss took a trip to sunny Orlando to present at Tech-Ed and to offer help and suggestions in the Technical Learning Center (TLC). This year I'm lucky enough to be attending with a couple of other folks (Habib and Tim) and since I'm not an official Speaker I'll be spending most of my time hanging out in the Application Lifecycle Management (ALM) demo station for Visual Studio 2008 Team System, Development Edition.
We've prepared a few demos covering things like:
We're also looking forward to discussing your specific scenarios so if you're at Tech-Ed and interested in diagnostic tools and solving performance problems we'd love to chat with you.
I use a bunch of Sysinternals tools for diagnosing problems while developing. My two favorites are:
Recently the Sysinternals tools have been hosted on a new live site that can be accessed via the web, or as a file share. Now I can easily run a Sysinternals tool and be sure that it is the newest version:
I can also update my own local cache of useful tools by periodically copying from the file share.
Ian previously covered using the VS 2008 Data Collection Control to choose when to collect data. The Data Collection Control can also be used to insert marks into the performance report, but sometimes it is convenient to modify the source code to do this automatically.
Consider a typical application (PeopleTrax) where I am interested in gathering profiler data only between when a button is clicked and when data is displayed. The application is shown below.
After the 'Get People' button is clicked, data is displayed after just over 6 seconds. This seems a little excessive so I want to focus my performance investigation in this area.
To filter the data so that it only shows information collected between those two points, I could use the Data Collection Control, but maybe I'm planning to run a complicated scenario and don't want to have to remember to insert the marks manually. Instead, it is possible to modify the original code to request the profiler insert marks in the required locations.
The Profiler API is available for managed code in an assembly that can be added directly to the project from \Program Files\Microsoft Visual Studio 9.0\Team Tools\Performance Tools.
After adding the reference it shows up in the 'References' list for the PeopleTrax project.
I can then use functions in the Profiler API to control the profiler. This might include starting or stopping data collection or in this case, inserting marks into the datastream. This is easily achieved as shown below.
I can then profile the application and when I open the Performance Report and switch to Marks View I see that the marks have been correctly inserted. We can also see that the time elapsed between the marks is about 6.5 seconds, which corresponds with the measurement that is already displayed in the PeopleTrax UI.
I can use the marks to filter the report to only show profiling data for the time between the two inserted marks and then start my performance investigation.