Visual Studio Profiler Team Blog

VS2010: Profiling In Progress (PIP)

With Visual Studio 2010 we want to make it clearer when you are profiling your application within the Visual Studio IDE. To accomplish this we added a new control which we call ‘Profiling In Progress’ or PIP, which we show when you launch the profiler or attach the profiler to a running application.

Our goal was to show something simple and lightweight while profiling and to make a few simple operations possible. PIP in VS2010 is shown below:

Currently profiling. Pause profiling. Stop profiling or exit the application to generate a report.

The progress/spin control indicates that the UI is responding and there are two links:

• Pause profiling, which changes to ‘Resume profiling’ when clicked. This has the same effect as clicking on the ‘Pause profiling’ button in the Performance Explorer.
• Stop profiling, which kills the application and finishes profiling.

After profiling completes, PIP changes to show that we are about to open the report.

Preparing to open report… This might take a while if your symbol server is slow or not responding.

 [Colin Thomsen]

VS2010: Using profiler to improve cache data locality

A recent Concurrency Hazards: False Sharing article demonstrates how VS2010 profiler can be used to detect source of cache data locality issues. To achieve this, you can sample with cache specific CPU performance counters, as long as you do not run inside Virtual Machine or on Hyper-V enabled environment (and this is why).

In post-VS2010 Beta 2 releases you can use Last Level Cache Misses and Last Level Cache References counters for that purpose:

[Maxim Goldin]

VS2010: Investigating a sample profiling report (Function Details)

I’ve already discussed how the new profiler summary page makes it easier to discover and fix performance issues, but sometimes a little more investigation is required. This time I’m going to drill in with another new VS2010 feature called the Function Details View.

I’m going to use PeopleTrax application again, which you can download from CodeBox. I have a report which I collected earlier using the Sampling method of profiling, since the application appears to be CPU bound (at least on a single core).

In this report I take a look at the Hot Path and see that People.GetNames is calling two hot functions ‘StringReader.ReadLine()’ and ‘String.Trim()’.

I’d like to see where these expensive calls are in my code so I click on GetNames (shown in purple above) to bring up the new Function Details view.

There are a few things to note about this new view.

• The title at the top is for People.GetNames().
• There is a dropdown to switch between ‘Inclusive Samples %’ and ‘Inclusive Samples’
• There are some blue boxes showing callers and callees (I’ll cover this more later).
• The code is shown with hot lines and an annotated margin.

In the default view we would need to drag the splitter (shown in purple) to see all of the boxes. Instead, we can use the toolbar option to ‘Split Screen Vertically’, also highlighted in purple.

Now we can clearly see where the calls to ReadLine() and Trim() are in the code on the right-hand side. There is also a metrics table in the ‘Function Performance Details’ section and there are some related links.

At this point, let’s look at the blue boxes. The left-hand box shows the callers of this function. The height of the box represents the relative cost for the metric that is currently chosen (in this case Inclusive Samples). Since we have a single caller, it takes up the entire box.

On the right we have another blue box that contains several sections:

• Function Body (87 samples). The height of this box represents the relative number of samples in the body itself (Exclusive Samples).
• ReadLine (727 samples). This is the function with the most Inclusive Samples. Again, the height is proportional so it is also the biggest box.
• Trim (642 samples). The function with the second most Inclusive Samples. Slightly smaller height.
• Other functions with smaller sample counts.

Each of these boxes (aside from Function Body) is clickable, allowing navigation of the Caller/Callees.

Looking at the code I can’t see an easy way to simplify it and I don’t control either Trim() or ReadLine(), so now let’s navigate one level up in the callers by clicking on GetPeople.

Clicking causes us to navigate to the GetPeople Function Details view:

From the code on the right-hand side we can see that in the two highlighted calls to GetNames 89.2% of the samples are occurring. From the loop structure it seems like it would be a good idea to avoid making these GetNames calls inside the for loop. Followers of the PeopleTrax application will notice that this is the first optimization suggestion for this application – cache the GetNames calls in the constructor. The next step in this investigation would be to change the code, collect another profile and compare the reports, but I’ll leave that up to you.

NOTE: line-level information is only available for sample-profiling. Since this information is not available in Instrumentation mode, highlighting and margin annotation is also not available for Instrumentation mode.

[Colin Thomsen]

PRF0025: No data was collected – why is that?

One day, you may try to use Visual Studio profiler to sample an application you develop, and end up with an error saying no data is collected:

Profiling started.
Profiling process ID 2752 (<Your Application Name>).
Process ID 2752 has exited.
Data written to C:\<some path>\Report100114.vsp.
Profiling finished.
PRF0025: No data was collected.
Profiling complete.

There could be number of reasons for that.

The first question I will ask: “Is your application CPU bound?”. If your process doesn’t use CPU intensively enough during the profiling session (it waits on IO instead, for example), than the process becomes “invisible” for default profiler sampling (as events that trigger a sample happen when other applications are running – see my previous post explaining different samples and what they mean). If you use advanced sampling, configuring some specific CPU Performance Counter (through either /COUNTER command line option, or using Visual Studio UI) – for example, L2 Cache Misses – then again, if your application doesn’t generate samples of that specific event, no data will be collected. In those cases you may try to switch to Instrumentation mode.

If, however, you are sure your application is CPU bound as you see CPU spikes during its execution, yet Visual Studio claims “no data was collected” – please look into Properties of the collected file (you can get it by pressing F4). In some rare cases you will see all collected Samples are set to 0. Which means no sample was collected at all (normally, even if your application is not CPU bound – samples are collected, but they belong either to kernel mode, or other applications; Total number of samples equal to 0 is something really strange). The question I will ask in this case is: “Did you use any other diagnostic tool recently? Especially those, that are not developed by Microsoft?” And if you answer “Yes”, please reboot your machine and try again. The reason is that some tools may leave your machine hardware in a state that breaks functionality of Visual Studio profiler. Reboot will fix it for you.

[Maxim Goldin]

VS 2008 Profiler and Nehalem Intel Processor

When you run VS 2008 SP1 profiler on Intel Nehalem CPU based machine, you may experience crash of operating system (blue screen).

This problem occurs because the sampling profiler uses a kernel mode driver in the operating system. However, the Intel Nehalem processor was created after the release of the 2008 version of the profiler, thus profiler could not be completely compatible with the Nehalem processor before the release. There is a hot fix for this problem – KB958842 – which you need to install to resolve the problem.

On some versions of Nehalem family there is no blue screen experience, rather profiler doesn’t seem to work. For example:

Or:

Error VSP1398 : The monitor was unable to start the VS performance driver.  The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. Consider using the /Admin:Driver,Start and /Admin:Security options of VSPerfCmd from an elevated environment.  Profiling cannot continue.

Error VSP1341 : Could not start logging engine.  Shutting down.

Error VSP1394 : Could not start profile monitor

The reason of the problem is the same, and the KB958842 is the remedy for this case as well.

Needless to say, the problem is taken care of in new version of profiler that is released in Visual Studio 2010.

[Maxim Goldin]

Visual Studio Profiler in Virtual Environment

Visual Studio profiler usage on virtual machines was limited so far, as it didn’t support Sampling mode in such environment. I’m glad to note that in Visual Studio 2010 you can sample your applications inside of virtual machines. VMs could be created using either VPC, VMWare of Hyper-V technologies.

Some hardware is not virtualized, though, and CPU performance counters (that are used by profiler) are, unfortunately, in the list. To overcome the issue, we used a different approach that targets each VM-vendor specifically, and timers that are used in virtual world are not the same as on a raw hardware. Some functionality, however, suffers from lack of CPU performance counters virtualization. Thus, you obviously cannot explicitly sample with those counters (instead of default one), and an attempt to do so will result in an error message:

Error VSP1478: Performance counters are not supported on virtual machines.

So, you cannot sample with Instructions Retired, L2 Cache Misses, Branch Mispredictions and other fancy counters provided by HW vendors.

Instrumentation mode of profiler inside of VM has some limitation as well. Explicit usage of CPU performance counters (through /COUNTER option of VSPerfMon.exe or VSPerfCmd.exe command line tools, or through Visual Studio UI) results in the same error. Default usage of Instrumentation will warn you that a difference between Elapsed (user mode + kernel mode) and Application (user mode) times for each function will not be detected:

Warning VSP2317: The monitor was unable to acquire a hardware performance counter for detection of kernel mode execution. Elapsed and Application time will be the same.

But apart from this difference, Instrumentation mode works just fine.

One word of caution. You may be confused to see those errors/warning about non supported performance counters on a real, non-virtual machine. It could happen if your machine has CPU virtual technology enabled in BIOS, and a hypervisor role is added to operating system (Hyper-V, for example). In this case, your operating system runs on top of hypervisor and, in fact, becomes virtual (even when you logged in to a real machine, and didn’t create any virtual machine there). So, if that happens and you want to use CPU performance counters – all you need to do is to remove hypervisor role in your OS and disable virtual technology in BIOS. After that you can use profiler as usual.

[Maxim Goldin]

How to Profile NUnit tests using the Visual Studio 2010 Profiler

Profiling NUnit tests can be achieved in a few simple steps. The first step, of course, is to decide on which method of profiling is best suited to analyze the performance of your unit test. One of my earlier posts addresses this question, which you can find here. In this post, I will use “CPU Sampling” to illustrate the steps necessary to profile NUnit tests. In a future post (hopefully in not so distant future), I will put together a similar post for using the “instrumentation” method.

One Item to Note Before You Start

NUnit has a built in feature called “Shadow Copy”, which [as it appears on the surface] moves the test and application binaries to a temporary location before running the tests, and removes those DLLs from the temporary location when it is terminated. Depending on how your test and application’s binaries are setup to interact with one another, the Profiler may not be able to accurately locate the correct binary during its analysis stage and would not be able accurately tie back the collected performance data to source code. Therefore, you may want to consider disabling shadow copy when profiling NUnit tests. In NUnit, you will find this option under Tools -> Settings.

Figure 1 - Disabling Shadow copy in NUnit

Profiling NUnit Tests in “CPU Sampling” Mode

The first step to analyze the performance of any binary is to create a performance session. The easiest way to create a performance session is to use the Alt-F2 shortcut to launch the wizard. Alternatively, you can launch the performance wizard from the “Analyze” menu.

On the first page of the wizard, choose “CPU Sampling” and then click “Next”

Figure 2 - Select CPU Sampling on Performance Wizard

On the second page of the wizard, select “An Executable (EXE File)”, and then click “Next”

Figure 3 - Select "An Executable" on Performance Wizard

On the third page of the wizard, you will see 3 text boxes. Since we are profiling NUnit tests (which are DLLs) we need to tell the profiler which executable should be used to run the desired NUnit tests. Therefore the first piece of information we need to provide profiler where to find NUnit.EXE.

Then we should have the profiler, tell NUnit.EXE how to find the test DLL, by providing a path to the test DLL on the “Command-Line Arguments” text box. Finally, we should make sure that the working directory is set correctly and that NUnit can locate all the binaries it needs. Once the information is provided, click “Next”

Figure 4 - Tell Profiler which application to Launch on Performance Wizard

On the last step of wizard, keep the “Launch profiling after wizard finished” check box checked, and click finish.

Figure 5 - Last page of the Performance Wizard

Once NUnit is launched, run the tests as you normally do. When finished, close NUnit.

Figure 6 - Run your tests using NUnit GUI application

The Profiler will then analyze the data it has gathered and will display the performance report.

Figure 7 - Profiler Report

[Daryush Laqab]

VS2010: New Profiler Summary Page

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.

[Colin Thomsen]

Using the keyboard to profile an application (Alt-F2 shortcut)

In announcing 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 have 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.

[Colin Thomsen]

Multi-Tier Performance Analysis

Think of a typical three-tier application; the one that has, let’s say, an ASP.NET UI, a business logic layer, and a data access layer which talks to a SQL Server instance. Ever wondered which queries are executed as a result of serving a page? Ever wondered how long it takes to execute those queries? Ever wondered which one of those queries is the one taking the most time and slowing down your application?

Let me introduce you to Tier Interaction Profiling, the first Multi-Tier Performance Analysis feature in Visual Studio. Tier Interaction Profiling enables you to measure the performance of your application from a database interactions point of view. Let’s take a look at a screenshot:

Figure 1 - Tier Interaction Profiling Report

Tier Interaction Profiling (TIP) report follows a master-detail approach. Sections 1, 2, and 3 are in the master section, while sections 4 and 5 are in the details sections. These sections are:

1. This section looks a little different depending on whether your application is an ASP.NET application or a Windows application. If you are profiling a windows application, you will see the name of the EXE. On the other hand, if your application is an ASP.NET application, TIP will show you each page (and other artifacts like JPG or CSS content) requested during your profiling session.

2. If any web page (or Windows application if you are profiling a Windows application) makes use of a database connection (either directly or through an intermediary layer), TIP will display information about that connection. TIP groups the data about connections by connection string. For each connection, TIP will also show you the sum of the queries executed during the requests made to the web page (or Windows application) along with its total execution time. Once you select a connection, TIP will show you details about queries executed via that connection (see sections 4 and 5 below).

3. For each web page, TIP will show the number of times the page was request along with Total, Minimum, Maximum, and Average time spent on processing the request s.

4. For each connection selected in the master section, TIP will show the queries executed. As the connections (in section 2) are grouped by web page request (or Windows application run), you are in effect looking at the queries executed as a result of making that web page request. TIP shows you the actual command text of the query. If you are using stored procedures, TIP will report the stored procedure name. If you are using LINQ, TIP will show the SQL generated for the LINQ query.

5. For each query, TIP displays the number of times the query was executed along with Total, Minimum, maximum, and average time spent executing that query. Similar to section 4 and as the connections are grouped by web page request (or Windows application run), you are in effect looking at performance information for a given query (or stored procedure) as a result of execution of a web page.

Figure 2 below is a depiction of a typical 3-tier application. The green arrows indicate where TIP interjects itself to collect performance data points; the black arrows indicate places which TIP excludes from its performance data point collection:

Figure 2 - TIP Data Point Collection Areas

Where do I find Tier Interaction Profiling

There are two ways in which you enable TIP for your profiling session. First, when creating a performance session for a web application through the performance wizard, you can enable TIP by selecting it as an option for your performance session:

Figure 3 - Enabling TIP on Performance Wizard

The other way is to enable TIP for the entire performance session or any of the performance session targets. You will find the Tier Interaction Profiling session option in the session or target properties:

Figure 4 - Enabling TIP on Performance Session Properties

You are now ready to profile your application. Once you have enabled TIP and you have run your application under profiler, you can access “Tier Interaction” report from the list of available reports:

Figure 5 - Where to find Tier Interaction report

Start using Tier Interaction Profiling

Vast majority of 3-tier application performance bottlenecks are in how the application utilizes the database. Prior to VS 2010 Profiler, one needed to employ a large set of breakpoints, debugger traces, and SQL Traces to identify which query is being called the most and which query takes the longest to execute. With Tier Interaction Profiling in VS 2010 Profiler, you are merely a few clicks away from a report showing you the exact call count and timing information for each query executed in your application.

[Daryush Laqab]

Which Profiling Mode Should I use?

Short Answer:

Longer Answer:

So you have an application that is not performing as you anticipated and you want to know what is going on. Naturally :) you go to Analyze menu and choose “Launch Performance Wizard…”. There comes the first page of the performance wizard asking you to decide on one of the four available profiling modes before letting you proceed to the next step:

But which one is the right one for your application? The following is a brief description of what you can expect from each mode of profiling to help you better decide which profiling mode to choose.

CPU Sampling

Sampling is a basic, yet powerful mode of profiling that can identify which method in your application are using too much CPU. Sampling has a very low overhead, but it is amazingly powerful in spotting performance issues. You can expect profiler to report a relative measure of how much work each method performed individually. You can also expect to see a relative measure of how much work each method caused other methods to perform.

The way these relative measures are gathered is through “Inclusive” and “Exclusive” samples. Take a look at the following picture:

When you profile your application in Sampling mode, profiler will examine the execution call stack at pre-defined intervals and collect samples. For each method on top of the call stack, it collects one “Exclusive” sample. For all methods on the call stack (including the method on the top), the profiler collects one “inclusive” sample. Once you done profiling the application, the profiler will tally up all the sample counts for each method. The methods with the most number of “Exclusive” samples are doing a lot of individual work (since they have been on the top of the call stack a lot). Methods with the most number of “Inclusive” samples are causing a lot of work to be done (since they have other methods above them on the call stack).

Sample profiling mode is most suited for CPU bound applications, as it only collects samples when the application is using CPU. Therefore, you may not collect enough samples if your application often blocks on external kernel calls (e.g. blocks a lot on I/O or Network). That is where you would want to use Instrumentation profiling.

Instrumentation

Instrumentation mode will provide you with exact call counts and exact time your application spent executing each method, including the time a method was blocked on external kernel calls. In order for profiler to collect exact call counts and exact execution time for each method, it needs to insert probes into your code (e.g. Instrument your code).

Here is how probe insertion works:

Using these inserted probes, profiler computes “Elapsed Time” and “Application Time” for each method. Elapsed time is the time spent inside a method, whether that method is executing instructions or is blocked on external calls. Application time, on the other hand, is the amount of time a method spent doing individual work and was not blocked.

During the instrumentation process, each method is enclosed by a set of “METHOD_ENTER” and “METHOD_EXIT” probes. Then, each  call that leaves the current assembly is wrapped by a set of “CALL_ENTER” and “CALL_EXIT” probes. Profiler will then counts the number of “METHOD_ENTER” and “METHOD_EXIT” probe hits to identify the exact call counts for each method. Profiler will then use the time spent between the probes to calculate Application and Elapsed time (I am skipping over a lot of details here that deserves its own post).

So far, we have only been concerned with “Time” as a measure of performance. Obviously, time is not the only resource an application uses. Memory is another one. Profiler can help you identify how much memory your managed application is using. That brings us to the third profiling mode.

.NET Memory Allocation (Sampling)

.NET Memory Allocation mode uses the same approach as Sample Profiling mode, but instead of collecting samples at pre-defined intervals, profiler collects samples anytime an object is allocated. When an object is allocated, profiler will capture the type and size of the objects allocated. You can expect profiler to identify the methods that have allocated most amount of memory, as well as types with the most amount of memory and most amount of instances during the profiling session.

In addition to collecting object allocation data, profiler can also capture object lifetime information. More on object lifetime will follow below in the “Switching between different modes” section.

Concurrency

In Multithreaded applications, synchronization objects are used to control the “rhythm” of the application. However, how these synchronization objects are used and how the threads are organized and executed can vastly impact how your application performs. Concurrency profiling will provide you the information you need to analyze how well your application is utilizing synchronization objects and how well your application is taking advantage of parallelism.

When selecting concurrency mode, you must decide on at least one of the two collection methods:

The first option is Resource Contention mode. Resource contention mode is a low overhead method of concurrency profiling which (similar to CPU Sampling and .NET Memory Allocation Sampling) collect inclusive and exclusive samples of methods on the stack anytime a thread blocks on a locked synchronization object. When selecting Resource Contention profiling, you can expect profiler to report the list of most contented synchronization resources as well as the threads which had the most number of resource contentions.

The second option, concurrency visualizer, is a comprehensive view of how well an application is using parallelism. When selecting concurrency visualizer, you can expect profiler to report on the activities of threads during the profiling session as well as how well CPU and each core on the CPU was utilized. I encourage you to check out the concurrency visualizer blog.

Switching between different modes

Up to this point, we have focused on the first page of the Performance Wizard. Performance wizard walks you through the steps necessary to create a performance session. You can, however, change the profiling mode after a session is created. Profiling mode is found on the “General” tab of performance session properties:

It is via the General tab that you can enable .NET Object Lifetime collection or add .NET Memory Allocation and .NET Object Lifetime collection to instrumentation mode.

[Daryush Laqab]

VS2010: Attaching the Profiler to a Managed Application

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.

[Colin Thomsen]

Visual Studio 2010 Beta 2 Available Now!

On Monday, we released Visual Studio 2010 and .NET Framework 4 Beta 2 to the web!  In the new, simplified product lineup, you will find the profiler in the Premium and Ultimate editions.

We’ve made a lot of progress since Beta 1 with the profiler and with the product in general.  We would love to get your feedback and impressions on it:

• Post issues and questions in the Beta 2 support forums
• Submit bugs or suggestions through Microsoft Connect
• Tweet your experiences with the #vs2010 tag

Our Beta 1 feature blogging was put on hold in favor of fixing bugs, so as we inch closer to RTM, we will be posting in-depth information about the new goodness in the profiler as a part of Visual Studio 2010.

Until then, I leave you with a little more screenshot love :) (click to embiggen)

Fig 1. New summary page.

 
Fig 2. Function details view.

Fig 3. Thread contention view.

Fig 4. Tier interactions view.

Fig 5. Performance wizard.

Fig 6. We’re on the Debug menu! I <3 Alt+F2.

[Chris Schmich]

Write Faster Code with VS 2010 Profiler

Well, Visual Studio 2010 Beta 1 is finally here!!! WooHoo. As you may have seen in Brian Harry’s blog , we have added quite a few new features to Profiler to help you write faster code. The following is a list of the new features. In this list, I have also included a note on which features work for managed versus native (where applicable, of course). By the way, this is just an overview and we’ll be drilling into the details on these features in the weeks ahead:

Virtualization support for sampling (VPC, Hyper-V, VMware)

You can now use VS 2010 Profiler to sample profile an application (both native and managed) on a virtual machine, irrespective of whether the virtual machine was created using VPC, Hyper-V or VMware. The timers used for profiling are different on virtual machines than raw hardware, and I will elaborate more on this on a future blog post. By the way, all the screenshots you see below have been gathered on a Hyper-V virtual machine while sample profiling the Dinner Now and Beer House applications.

New Summary and Function Details reports

The Summary page has gotten a “total makeover” and is a lot more actionable than the summary page in VS 2008. The data on the summary page is going to look different depending on the method of profiling you choose, but regardless of the method of profiling, you can visually identify the performance spikes in your application and navigate to the top 5 methods by just a click.

VS Profiler 2010 includes a new page called the Function Details page. The following is a screenshot of the Function Details page, which will depict the caller/callee information in a graphical way along with the performance metric. There is also an embedded, editor which includes the line-level performance measurements.

Both Summary and Function Details pages are available for managed and native applications.

Tier Interaction Profiling (TIP)

Tier Interaction Profiling (TIP), enables you to see the number of times a query (or stored procedure) was executed in your application, and to see the amount of time you spend inside of ADO.Net for that query. This feature is turned on via the session and target property pages, and once it is run, you will see an additional profiler report called Interactions (see below). As this feature only works with ADO.Net at the moment, it is only supported for managed applications. And, by the way, if your application is a web application, TIP also shows you the number of times a page was called and the processing time for that page:

Client Side JavaScript Profiling for IE 8

When incrementing a web application, you can now turn on JavaScript profiling via the session or target property pages to see the performance of your client-side JavaScript (including Ajax calls back to the web server). JavaScript functions will be included in your report alongside the methods from your web application.

Concurrency Profiling

Concurrency profiling is a new method of profiling added to VS Profiler 2010 enabling you to profile your multi-threaded applications to see how your threads are behaving inside the application. There are two sub-modes for Concurrency profiling, which I will elaborate more on during a future blog post. Screenshot below shows the place in performance wizard where you can select concurrency profiling. Suffice to say for now that there is lightweight “Resource Contention” profiling and a more comprehensive “Thread Execution” profiling, each of which adds their own reports to profiler results. This feature works for both native and managed applications.

Just My Code

Have you ever wanted to exclude framework related information from your profiler reports so that you can look only at the data related to your code? You can now, with Just My Code feature. Just My Code reduces the noise in your profiler reports by removing framework related measurements. Just My Code works for both native and managed and applies only to sampling mode (in Instrumentation you specify the binaries you wish to profile, so it is “Just My Code” by default). There will be more detailed information on Just My Code to come in future blog posts from Profiler team.

CLR 4.0 Attach

When profiling applications written using .Net Frameworks 3.5 and below, some environment variables need to be set in the process. The Visual Studio IDE does this for you, but when profiling with the command line tools, you need to set up the environment variables using VSPerfCLREnv.cmd. In Dev10, you can attach directly to any v4.0 managed process to do Sample profiling using VSPerfCmd.exe /attach:PID.

Rich integration with the editor

Rather than me writing about what it does, why don’t we just look at the screenshot below:

As you can see, the code is color coded depending on the performance data collected (in this case, the hottest line). Editor integration is available for both native and managed applications.

Built-in Rules and Guidance

VS 2010 analyzes the performance data collected during the performance run and will use pre-defined rules to recommend a few areas for further investigation. These recommendations will be displayed in the “Error List” in Visual Studio (double clicking the warning will bring you to the profiling data that triggered the rule or a help document about the rule). You can modify and expand upon these “Rules and Guidance” by writing your own rules (another blog post to be provided in the near future). The rules are available for both managed and native applications.

[Daryush Laqab]

Visual Studio 2008 AJAX Profiling Extensions Power Tool

Originating in Microsoft Research as Ajax View, the Visual Studio 2008 AJAX Profiling Extensions Power Tool was released today (download here).  It’s a JavaScript performance profiler with a novel approach: it modifies the code sent by your server to include diagnostic code to trace and time function execution.  The client browser then sends profiling data back to your server for aggregation and analysis as the JavaScript executes.  Once you’ve collected your data, you can install the power tool extensions for VS2008 Team Developer or Team Suite to view and analyze the results using the Visual Studio Profiler’s UI.

The benefit of the server-side instrumentation approach is that it works with any client browser, letting you see how various browsers affect your performance.  On the server, you must be running IIS7 with an integrated pipeline.  Currently, running this power tool on production servers is not recommended.

Between this power tool, the built-in IE8 JavaScript profiler, and the integration with Visual Studio, we hope to shine much needed light on client-side browser performance.

[Chris Schmich]