With Visual Studio 2010 we want to make it easier for customers to find and fix performance issues with their code. One of the first things we looked at was the view that shows up after profiling an application – the Summary Page.

I’ll describe a few features of the new summary page using the PeopleTrax application, which you can download from CodeBox. I won’t describe collecting the profiling data since this is already covered on MSDN. The summary page for a sample profiling run is shown below.

I’ll describe the individual pieces of the report below:

• The header shows the type of data collected (Sample, Instrumentation, etc.) and also how many samples were collected.
  
  
• The hot path is shown right on the front page.
   
  We can see straight away that the ReadLine() function is an interesting function to look at. Clicking on the hyperlink will take you directly to the Function Details page. There are also related views links to navigate directly to the ‘Call Tree’ and ‘Functions’ views.
  
• Functions that are doing the most individual work (have the highest Exclusive Samples) are listed with visual ‘sparklines’ (bar charts) to indicate relative importance.
  
  Clicking on the hyperlink for a function takes you directly to the Function Details page for that function.
  
• Notifications that change based on the state of the report are shown in a new ‘Notifications’ area. In the example below, clicking Show All Code will reanalyze the report with Just My Code turned off. ‘View Guidance’ will bring up the Error List to display guidance from the new Rules and Guidance profiler feature.
   
  
• Action links are shown in the ‘Report’ area and they do not depend on the state of the report. One useful link we added is ‘Toggle Full Screen’ which shows the report in full-screen mode.
  
  
• A chart of CPU usage (for sampling, although we also show contention data in Concurrency mode) enables filtering of the report data. Highlight a region on the chart and choose ‘Filter by selection’ to show data from only that period of time. For example, with the chart below it may be useful to filter between 16 and 24 seconds.
  
  
• At the top of the report above the header, we still have the profiler toolbar which is useful for navigating (see the left and right arrows and also the dropdown for jumping between views) and for executing some of the actions that are also listed on the Summary Page.
   

Hopefully these new features on the front page will make it quicker and easier than ever to diagnose your performance issues.

In announcing the Visual Studio Beta 2 profiler features, Chris mentioned that we have a new option on the Debug menu called ‘Start Performance Analysis’ which has the Alt-F2 keyboard shortcut. This makes it easier than ever to start profiling your application. The new menu item has the following behavior:

• You must have a Visual Studio Solution open in order to enable it.
• If you have a solution open, but do not have a launchable current performance session, Start Performance Analysis launches the Performance Wizard.
• If you have a solution open and have a launchable current performance session, Start Performance Analysis starts profiling.

Let’s use this new functionality to profile an application that I prepared earlier.

1. Open the solution with ‘Alt-F, J, Enter’:
    
2. Start Performance Analysis with ‘Alt-F2’, which brings up the wizard:
   
3.   Press ‘Enter’ to choose the default ‘CPU Sampling’ profiling method and move to the target selection page:
    
4. Press ‘Enter’ to select the only launchable project in the solution and move to final wizard page:
   
5. Press ‘Enter’ to finish the wizard and start profiling:
   
6. The report will open when profiling finishes:
    

If you wish to profile again, selecting Alt-F2 will start profiling with the Performance Session that was created after step #4.

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:

• vsperfclrenv /sampleon
• [Start managed application from the same command window]
• vsperfcmd /start:sample /output:myapp.vsp /attach:[pid]
• [Close application]

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.

Caveats:

• We only support attach without environment variables for basic sampling. It will not work for Allocation or Object Lifetime data collection and Instrumentation attach is not possible. Concurrency (resource contention) attach is supported.
• The new attach mechanism only works for CLR V4-based runtimes.
• The new attach mechanism will work if your application has multiple runtimes (i.e. V2 and V4  SxS), but as noted above, you can only attach to the V4 runtime. I’ll write another post about the profiler and Side by Side (SxS).
• The old environment-variable-based attach still works, so you can still use that if you prefer.

The new procedure for attaching the profiler to a managed application in Visual Studio 2010 goes like this:

• Launch your app (if it isn’t already running)
• Attach to it, either from the command-line or from the UI.
• When you’re finished, detach or close the app to generate a report.

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.