Visual Studio Profiler Team Blog

The Visual Studio Profiler on Windows 8

Andrew B Hall - MSFT — Mon, 10 Dec 2012 17:39:35 GMT

Windows 8 brought a lot of great changes to Windows including a stronger security model and new capabilities for performance tools. I am excited about how the new capabilities allow us to deliver new performance tooling not previously possible, e.g. the JavaScript Memory Analyzer for Windows Store apps. However because of the stronger security model there was also some impact to the existing profiling tools on Windows 8. In this post I will discuss the change to Windows that required us to redesign the way the Visual Studio Profiler works and the resulting impact to profiling features on Windows 8.

Note: The changes discussed in this post are only applicable when running Visual Studio on Windows 8, there are no changes to functionality on Windows 7.

Background

In order to understand why profiling functionality is different on Windows 8, I need to start with a brief overview of the profiler’s implementation. Once you understand how the profiler was implemented in Visual Studio 2010, the behavior differences on Windows 8 should make more sense.

All versions of Visual Studio through 2010 rely on a kernel mode driver to collect data. The driver was originally developed for CPU sampling so it can register for a callback based on CPU clock cycles (the default is 10 million cycles) in order to sample at a regular interval. Data collection for .NET Memory Allocation, and Concurrency profiling were then also integrated into the driver. Instrumentation profiling is a bit different because it does not rely on the driver for the instrumentation data, but it does use the driver to calculate application time (you’ll see why this is relevant below).

The changes

The profiling driver was registering for the callback in a way that interfered with a Windows kernel operation; and Windows 8 added a security feature that detects when non-operating system code registers for a callback in this. When this condition is detected, Windows does a bug check that results in a blue screen since the operating system can no longer trust the integrity of the kernel. However the supported way to register for the CPU cycle callback does not allow the callback handler to inspect information about user processes due to security concerns.

Since the driver was now at odds with the enhanced security model we needed to move away from the driver to the new capabilities of Windows added since the driver was first created for Visual Studio 2005.

Impact on Visual Studio 2010 and prior versions

Unfortunately, given the need to rewrite the collection and analysis components we were not able to release an update to Visual Studio 2010 to fix the issue. Since customers don’t want to blue screen their operating system, Windows 8 added logic to prevent all incompatible versions of the profiling driver from starting (2010, 2008, and 2005).

This means that when you try to start profiling with an incompatible version you will receive the message “Error VSP1398: The monitor was unable to start the VS performance driver. Access is denied. Consider using the /Admin:Driver,Start and /Admin:Security options of VSPerfCmd from an elevated environment.”

Which will result in the following behavior when running Visual Studio 2010 (or earlier) on Windows 8.

CPU Sampling, .NET Memory Allocation, and Concurrency profiling will fail to start on Windows 8. The only workaround on Windows 8 is to use Visual Studio 2012 Professional or higher, or to profile on Windows 7.
Instrumentation profiling can be launched, but the application and elapsed times will be exactly the same (this should have little impact on your ability to analyze the report, just note the elapsed time on the title bar of the summary page may not match the length of your profiling trace).

Impact on Visual Studio 2012

In Visual Studio 2012, we had to stop using the now incompatible driver for CPU sampling and instead use ETW (Event Tracing for Windows). However the move to ETW required a complete rewrite of the collection and analysis components for sampling, which unfortunately due to resource constraints meant we did not have time to add all of the existing sampling functionality to the new implementation. This has the following impact when profiling on Windows 8:

Tier Interaction Profiling (TIP) data cannot be collected in conjunction with CPU sampling data (this continues to work with instrumentation profiling, and on Windows 7).
The “Sampling” performance session properties cannot be configured, instead you will see the message “These settings are not supported for CPU sampling on this version of Windows” on the property page. It is important to note that CPU sampling works as expected with the default settings, it just does not allow for changing the advanced settings. The workaround to be able to use the advanced settings is to profile on Windows 7.
Windows performance counters cannot be collected while CPU sampling. The workaround is to use Windows 7 if you need to collect this information while sampling.
CPU samples for all functions executing inside NGEN’d modules will appear in the report as [NI module name], instead of the actual function name showing due to the way ETW reports the data (to resolve this see my blog post on Creating NGEN PDBs for Profiling Reports).
vsperfcmd.exe cannot be used to collect CPU sampling data from the command line and will fail with either the error code “VSP1535” or “VSP1336” and the message “To collect sampling data on this version of Windows, use vsperf.exe”). The correct way to collect CPU sampling data from the command line is to use vsperf.exe instead.

Hope this information is useful to some of you and please let me know if you have any questions.

VS2010: Just My Code

profiler1 — Fri, 13 May 2011 16:46:20 GMT

The ‘Just My Code’ feature in the profiler has a few differences to the ‘Just My Code’ feature in the debugger so this post should provide a useful introduction.

Example Program

Here’s a very simple program I’ll use in this post.

using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Foo();
        }

        private static void Foo()
        {
            double d = 0;
            for (int i = 0; i < 100000000; ++i)
            {
                d += Math.Sqrt(i);
            }
            Console.WriteLine(d);
        }
    }
}

Why ‘Just My Code’?

Typically when profiling you are most interested in optimizing code that you either wrote or you have control over. Sure, sometimes there will be issues in the frameworks that you are using or in other binaries, but even then you often control the calls into those frameworks. Just My Code or JMC is intended to filter the data that is displayed in profiler reports so that more of the code you control shows up in the reports and the reports are more manageable.

For example, the Call Tree after collecting sampling data for the simple program above, with JMC off, is shown below:

With the default JMC options, this reduces down to:

What is ‘My Code’?

There are two conditions for code being considered ‘My Code’ by the profiler and they are both at the Module level (Module Name column in the screenshots above). In the example above, this means the checks are made against the clr.dll, mscoreee.dll, mscoreei.dll and ConsoleApplication1.exe binaries.

Modules considered ‘My Code’:

the copyright string for the module does not contain ‘Microsoft’, OR:
the module name is the same as the module name generated by building any project in the currently open Solution in Visual Studio.

How do I turn JMC on or off?

You can temporarily toggle JMC on or off on the profiler Summary Page in the Notifications area using ‘Show All Code’ or ‘Hide All Code’ (shown in red below):

The default setting may be configured as discussed in the following section.

How do I configure JMC?

Use Tools –> Options –> Performance Tools –> General and set options in the ‘Just My Code’ section:

The default has JMC on, showing one level of non-user callee functions. In the example above with JMC on, this is why we see the call to COMDouble::Sqrt(dobule) showing up in the call tree.

It is also possible to show one-level of non-user code calling user code, which in the example above would add one level of the non-user code that calls main, as shown below:

Why is ‘Just My Code’ only available for sampling?

When you instrument binaries for profiling, you have already performed some level of JMC. Only binaries that you instrument and first-level calls into other binaries will show up in the instrumentation report, so JMC is not really necessary.

[Colin Thomsen]

How to Profile IIS Express with Visual Studio 2010 SP1

Andrew B Hall - MSFT — Mon, 02 May 2011 20:20:15 GMT

While IIS Express support shipped in Visual Studio 2010 SP1, unfortunately profiling code running in IIS Express does not just work out of the box. The issue is that the profiler does not “know” how to setup and launch the IIS Express process to enable the various profiling methods. If this is a blocking issue for you, fortunately this can be manually worked around to profile IIS Express.

The instructions for how to do this, vary depending on the method of profiling you would like to use, and the target framework

CPU Sampling:

If you’re profiling .NET 4.0 after you’ve launched your site in IIS Express, manually attach to the IISExpress.exe process (Analyze -> Profiler -> Attach/Detach…) and you will be collecting CPU sampling data
· If you’re profiling .NET <= 3.5:
- From a Visual Studio command prompt, type:
  - vsperfclrenv /sampleon
  - devenv
- From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the step for profiling .NET 4.0

.NET Memory Profiling (Sampling)

From a Visual Studio command prompt, type:
- vsperfclrenv /<memory option you want—see vsperfclrenv documentation for options>
- devenv
From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the CPU sampling scenarios

Instrumentation (including .NET memory instrumentation)

From a Visual Studio command prompt, type:
- For method timing: vsperfclrenv /traceon
  if you want memory, see vsperfclrenv documentation for options
- devenv
- vsinstr <your binaries that will run inside IIS Express>
- vsperfcmd /start:trace /output:<report name>
From the instance of Visual Studio that launches, launch your website in IIS Express and run your scenario
From the command prompt type: vsperfcmd /shutdown
Close IIS Express
Open the resulting .vsp file in Visual Studio

Resource Contention Profiling

Launch your website in IIS Express
From a Visual Studio Command Prompt:
- vsperfcmd /start:concurrency,resourceonly /output:<report.vsp>
- vsperfcmd /attach:<IISExpress.exe’s PID>
- Run your scenario
- vsperfcmd /shutdown
- close IIS Express
Open the resulting .vsp file in Visual Studio

“Performance reports must be created on a local drive”

profiler1 — Mon, 25 Apr 2011 22:26:17 GMT

For better performance, VS Profiler requires the report to be on a local drive. If you change the report file location through Performance Session properties page (right click on performance session in Performance Explorer –> Properties –> General):

then you end up with an error like that:

The rationale behind usage of local drives is that VS Profiler attempts to make logging to the file fast, while usage of network drives might introduce logging delays (up to blocking your application execution in some cases).

However, if you absolutely have to use your network drives for that purpose, you can achieve that through usage of Symbolic Links. A symbolic link can be easily created with mklink utility. For example,

mklink /D C:\Foo \\MyNetwork\MyValut

After that you can use C:\Foo as a location for profiling reports. Keep in mind, though, that your network access can be slower than a local drive access, and it can impact your profiling session.

[Maxim Goldin]

How to profile ASP.NET and Silverlight at the same time

Andrew B Hall - MSFT — Thu, 10 Feb 2011 03:40:39 GMT

In Visual Studio 2010 SP1 we enabled the ability to profile Silverlight applications from the Visual Studio UI. Unfortunately there is a limitation where we cannot automatically attach to multiple processes on launch from inside Visual Studio, so you are still unable to profile ASP.NET and Silverlight at the same time without manually attaching to Internet Explorer after launch. Fortunately, this is relatively simple.

To profile both Silverlight and ASP.NET at the same time:

Launch your CPU sampling session against your ASP.NET application from Visual Studio
In the Performance Explorer window click “Attach/Detach”
Select the Internet Explorer process that is running your Silverlight application—if you only have one instance of Internet Explorer open with a single tab, the process will be the “iexplore” process without a Window Title.
- If you have multiple instances of Internet Explorer open, or multiple tabs inside internet explorer, you can either:
  - Try looking at the CPU consumption of your iexplore.exe processes in Task Manager to see which one is most active
  - Use Process Explorer
    - Find –> “Find Handle or DLL…” (ctrl + F)
    - Search for “coreclr.dll”
    - The “iexplore.exe” process with this dll loaded is the PID you want to attach to
You are now profiling ASP.NET and Silverlight at the same time

VS2010 SP1: Silverlight 4 profiling from Visual Studio UI

profiler1 — Tue, 21 Dec 2010 18:13:28 GMT

If you install recently published VS2010 SP1 Beta , you can discover that VS Profiler team enriched Silverlight profiling user experience. Previously I published few posts about VS2010 usage for those purposes, either through VS Profiler command line tools or VS2010 UI. Both approaches led you to the final results or figuring out the bottlenecks of your Silverlight application, but they require number of manual steps to be done.

In VS2010 SP1 however Silverlight projects are fully recognized by VS Profiler, and you can conduct your performance investigations much easier.

For example, you might use the Silverlight Text Editor Sample, and open this project in VS2010 SP1:

Now, if you wish to create a performance session for this project, you can do it in a usual way through Performance Wizard:

You will see your project in the list of possible targets (it was not there before the final integration of Silverlight projects and VS Profiler), and you can select it there and proceed with the Wizard that creates and starts a performance session for you:

When you close your application – the session is over and profiling results are presented so you can analyze the data:

Enjoy!

[Maxim Goldin]

Tip: Fixing VSPerfASPNetCmd metabase errors

profiler1 — Fri, 23 Jul 2010 20:19:00 GMT

VSPerfASPNetCmd is a new Visual Studio 2010 tool that helps you profile ASP.Net websites from the command-line. Recently I noticed an error message which didn’t cover one common situation so I thought I’d write about it. Here’s an example:

> VSPerfASPNetCmd.exe http://localhost
Microsoft (R) VSPerf ASP.NET Command, Version 10.0.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

Error
VSP 7008: ASP.net exception: "The website metabase contains unexpected information or you do not have permission to access the metabase. You must be a member of the Administrators group on the local computer to access the IIS metabase. Therefore, you cannot create or open a local IIS Web site. If you have Read, Write, and Modify Permissions for the folder where the files are located, you can create a file system web site that points to the folder in order to proceed."

The information in the error is correct and it is worth checking to make sure that you are running from an elevated command prompt, but it does miss a common configuration issue. In order to query for information from the IIS metabase, certain IIS components need to be installed.

To check this in Windows 7:

Open ‘Control Panel\Programs\Programs and Features’ (or run ‘appwiz.cpl’).
Choose ‘Turn Windows features on or off’.
In the ‘Internet Information Services’ section, make sure that the following options are selected.

The non-default options include:

IIS 6 Scripting Tools
IIS 6 WMI Compatibility
IIS Metabase and IIS 6 configuration compatibility
ASP.NET,
Windows Authentication

[Colin Thomsen]

CPU Performance Counters in Visual Studio 2010 Profiler

profiler1 — Tue, 22 Jun 2010 16:05:08 GMT

While using Visual Studio Profiler either from Visual Studio UI or through command line tools, you may wish to collect more/different information using specific CPU Performance Counters. The collected data depends on the profiling mode. As usage of CPU Performance Counters considered an advanced technique, let me explain what is the proper way to use them and how to interpret the results.

First of all, CPU Performance Counters are not operating system performance counters, as they are implemented by CPU vendors inside of a CPU die.

If you run inside of a Virtual Machine or on a Hyper-V enabled machine – you have no access to CPU Performance Counters (as I mentioned in my previous post). This is the current limitation of virtualization technologies.

Let’s review 2 basic modes of VS Profiler – Sampling and Instrumentation – and discuss how the counters are used in each one of them.

Sampling

In Sampling mode, the profiler periodically interrupts an execution of your application in order to take a sample of it. The regularity of interrupts is achieved through usage of one of the CPU Performance Counters. By default – it is 10,000,000 Non Halted CPU Cycles. You can change the predefined sampling interval or the counter itself. When you change the counter, that means that you switch to a different event as a trigger of your samples. If the default Non Halted Cycles event causes your samples being collected when your application is actively using CPU, then switching to Last Level Cache Misses event, for example, will cause samples being generated on cache misses (so, if there are no cache misses – no data is collected).

VS Profiler supports sampling on only one counter at a time. Therefore, you can use only one counter when you configure your sampling session.

When you look through results of sampling, you will not see separate data columns with the counter name. Remember, that usage of specific counter in this scenario means that your samples were triggered by the counter event. So interpret your samples (inclusive, exclusive, function samples, module samples, call trees etc) appropriately.

To select a specific counter for your Sampling session in Visual Studio, go to Properties of your Performance Session (right click –> Properties), and select the Sampling tab. In Sample event drop down list switch default Clock cycles to Performance counter.

Now you can select one of the provided counters and set its Sampling interval.

The full set of counters provided by CPU vendors is quite big. VS Profiler suggests a sub-set of them, with an ability to add more counters to the selection if necessary. You will see all currently supported counters in VS UI. If you use command line tools for your data collection, you can see the counters through the following option:

C:\MyProjects>VSPerfCmd.exe /querycounters
Microsoft (R) VSPerf Command Version 10.0.30319 x86
Copyright (C) Microsoft Corp. All rights reserved.

Portable counters:
        InstructionsRetired
        NonHaltedCycles
        L2Misses
        L2References
        ITLBMisses
        BranchesRetired
        MispredictedBranches
Platform counters:
        DCULinesIn
        DCUModifiedLinesIn
        . . .

To use one of them, you need to provide the counter name in /COUNTER option of VSPerfCmd.exe when you start your data collection. VSPerfCmd.exe /? will give you an exact syntax. For example:

VSPerfCmd.exe /attach:MyApplication.exe /COUNTER:L2Misses,1000

Instrumentation

In instrumentation mode, VS Profiler records timestamps at function entries and exits. If you add CPU Performance Counters to the session, their values will be collected at the same time, and you will have separate columns of data for each counter. Unlike the sampling mode, you theoretically can add to instrumentation profiling session as many CPU counters as you wish. Practically, however, the number of counters you can use simultaneously is limited by a number of registers that are implemented in your CPU for that purpose. Sometimes it could be as few as two registers only, and VS Profiler always tries to acquire one of them for internal usage.

To add some Performance Counters to your Performance Session, go to the session Properties and select CPU Counters tab. There you can enable and select counters you want to add to your instrumentation data collection.

When you look at collected results, you will see new columns of data:

If number of counters that you select exceeds current CPU limitation, some of them will be dropped from the collection and you will get a WARNING message in the Output window:

Warning VSP2318: The monitor was unable to initialize counter 'Mispredicted Branches'.

While using command line tools, you can have multiple /COUNTER options to add several counters to your instrumentation session:

VSPerfCmd.exe /start:trace /output:MyFile.vsp /COUNTER:c1 /COUNTER:c2

Enjoy!

[Maxim Goldin]

Thread Performance: Resource Contention Concurrency Profiling in Visual Studio 2010

profiler1 — Tue, 08 Jun 2010 20:57:58 GMT

Does your native code deals with critical sections or other synchronization primitives?

Does your managed code uses C# lock statement or Monitor class?

If yes, and if you would like to get a clear picture of all contentions in your application, you might want to check out the new profiling mode of VS2010 Profiler – Resource Contention concurrency profiling. It collects and presents information about all contentions, when synchronization resources cause your threads to be blocked in an attempt to acquire the resource. Being contended, a thread doesn’t run. It waits. It wastes the time. It decreases the performance you wanted to gain from your super powerful multi-core machine, when you designed your application as a multithreaded in the first place.

For detailed explanation about how to collect contentions data, and what are the best ways to investigate it, follow the links.

Resource Contention Concurrency Profiling in Visual Studio 2010 – June 2010 MSDN article
Resource Contention Concurrency Profiling in Visual Studio 2010 – Performance Investigation Flows – a follow up blog to the MSDN article.

Resolve synchronization issues, if your code has any, and boost the performance of your application!

[Maxim Goldin]

VS2010: Silverlight 4 profiling from Visual Studio UI

profiler1 — Tue, 01 Jun 2010 19:40:11 GMT

In my previous post I showed how VS2010 Profiler command line tools can be used to profile your Silverlight 4 application, as this feature is only partially integrated with Visual Studio UI. While we are working on a full integration story, let me show you how VS UI can be used (with some extra work) currently to get same results as you get using the command line tools.

We will use the same Breakout Game example, which is open as a project in Visual Studio at the beginning:

As Silverlight project is not currently recognized by the Performance Wizard, you better start with creating an empty Performance Session. You can do it from the Analyze menu (Analyze –> Profiler –> New Performance Session):

or by clicking a New Performance Session button in Performance Explorer:

When a new Performance Session is created, it has empty Reports and Targets nodes. Now right click on Targets, select Add Target Binary and pick up c:\Program Files\Internet Explorer\iexplore.exe (or c:\Program Files (x86)\Internet Explorer\iexplore.exe, if you work on x64 machine):

Next step is to right click on iexplore.exe node, select Properties, and then select Launch tab in the Property Pages window. The “Executable to launch” is set already, but you should add Arguments and Working directory for your application.

The last preparation before you can start measurements is to make sure your Symbols setting includes the binary directory where the application is compiled. This is currently required for correct symbols resolution. You can find the Symbols setting in Tools –> Options –> Debugging –> Symbols (it is under Debugging and not Performance Tools, as both Debugger and Profiler share the same setting for Symbols).

Now you can click Start Profiling button in the Performance Explorer, and Internet Explorer will be started under profiler, running your application. As I mentioned in the previous post, there could be number of IE processes while your application is running. Yet Visual Studio attaches Profiler to only first of them, and doesn’t reattach it automatically to other spawned processes. Thus, you have 2 options here – either to eliminate creation of child processes by IE through the registry (modifying TabProcGrowth value), or attach profiler to additional IE process (one or many) before you start running your scenario. Simultaneous profiling of several processes is supported, and you will actually profile all IE processes that you attach the profiler to. Those processes that run your application will generate a valuable profiling data, while rest could be later ignored.

You can attach to additional processes using Attach/Detach button of Performance Explorer:

In our example, you can see in “Attach Profiler to Process” dialog that the profiler is attached already to one IE process, and now you will attach it to yet another one.

After you finish your scenario, close IE window and profiling results will be automatically open for you in Visual Studio, so you can navigate it using all views as usual:

Enjoy!

[Maxim Goldin]

VS2010: Silverlight 4 profiling

profiler1 — Mon, 26 Apr 2010 15:13:28 GMT

Did you know that Visual Studio 2010 Profiler allows you to profile your Silverlight 4 applications? You didn’t? It does.

This feature, however, is only partially integrated with Visual Studio UI, and you need to use command line tools to collect the data. After that, you can open the resulting .VSP file in Visual Studio as you normally do after other types of profiling, and enjoy rich visualization experience while investigating your performance problems.

Yes, we know it is not as cool as clicking VS buttons. We are working on a better experience. Yet I thought it is worth to emphasize that there is a way to use command line tools for customers that seek performance improvement in their Silverlight applications.

Let assume you develop an application like Breakout Game.

You compile it inside VS2010, run it, and want to profiler it. Performance Wizard tells you that this project can not be launched by the profiler. Alas. Time to go to the command line tools. Click you Start button, go to All Programs and find there Microsoft Visual Studio 2010. There, go to Visual Studio Tools and launch a Visual Studio Command Prompt (2010).

This command line window has predefined PATH that includes profiler command line tools:

Now go to the directory where your Silverlight binaries are compiled:

>cd c:\Breakout\Breakout\Bin\Release

We are ready to start our profiling session.

VSPerfClrEnv /sampleon
"c:\Program Files (x86)\Internet Explorer\iexplore.exe" C:\Breakout\Breakout\Bin\Release\TestPage.html
VSPerfCmd /start:sample /output:MyFile /attach:<PID of iexplore.exe process>
Run your scenario
VSPerfCmd /detach
VSPerfCmd /shutdown
VSPerfClrEnv /off

Steps above require some explanation. In 1 – you prepare environment that is needed for Silverlight profiling, and in 2 you start your hosting process (iexplore.exe, in our example) within that environment. This is essential, as if you start IE by clicking an icon on your desktop, you will get no Silverlight profiling data at the end. Step 3 starts profiler in Sampling mode, and attaches it to the process of your choice. Keep in mind that you might have multiple IE processes running, so you need to choose one that runs your code. If you are not completely sure which one is it, or if your code runs in several IE processes – well, attach to all of them! You can do it either running “VSPerfCmd /attach:<PidN>” several times, or enumerating all PIDs in a single command: “VSPerfCmd /attach:PID1,PID2,PID3”. After profiler is attached, you run your scenario in step 4, and detach profiler from all target processes in step 5. Detaching is not enough, as you need to shutdown the profiler in order to finalize your result file (step 6). Step 7 cancels changes of the environment that are made in step 1.

It could be that you need to profile your application from the very beginning. In this case steps 2 and 3 can be combined into one, where you launch IE under profiler:

VSPerfCmd /start:sample /output:MyFile /launch:"c:\Program Files (x86)\Internet Explorer\iexplore.exe" /args:”C:\Breakout\Breakout\Bin\Release\TestPage.html“

The caveat here is that if IE process spawns a child process that will run your application, the profiler will be still attached to the “father” IE process, as it doesn’t re-attach itself automatically to spawned processes. You may, however, eliminate creation of child processes by IE8 through the registry, modifying TabProcGrowth value.

Please make sure that you run all the above steps from the directory where your binaries are located. Until we complete the integration of this feature with VS, your function names will not be properly resolved otherwise.

You can kill you IE process now. Open the MyFile.VSP in VS2010 as you would do normally for profiling results.

Formally, that would conclude an official support of Silverlight profiling in VS2010 – Sampling mode through command line tools.

However, if you want to try .NET memory or concurrency resource contention profiling of your Silverlight application – I won’t stop you. This is not currently supported and tested modes of work, but they might work for you and help you to see your performance problems from a different angle.

For .NET memory profiling, use “VSPerfClrEnv /samplegc” or “VSPerfClrEnv /samplegclife” in your step 1 to get either allocation profiling or allocation and lifetime profiling.

For concurrency resource contention – use “/start":concurrency,ResourceOnly” in the step 3 above.

Oren Nachman from Sliverlight team is another excellent source for Silverlight profiling information. In his great article he provides several additional tricks and options that you can find quite useful.

Enjoy!

[Maxim Goldin]

Resource Contention Concurrency Profiling in Visual Studio 2010 – Performance Investigation Flows

profiler1 — Fri, 23 Apr 2010 07:17:22 GMT

Visual Studio 2010 brings a number of innovations to multithreaded and parallel computing. One of them is Resource Contention Concurrency Profiling. John Robbins gives a really great first look at this feature in his Wintellect VS 2010 Beta 2 Concurrency Resource Profiling In Depth First Look post. The June 2010 issue of MSDN magazine contains the Resource Contention Concurrency Profiling in Visual Studio 2010 article with a detailed explanation of this profiling mode, including various ways of data collection and presentation and some guidance to efficient data analysis. Here I would like to append the article with some additional valuable information.

The table below presents a subset of VS2010 performance data views. Those views are useful while investigating results of Resource Contention Concurrency Profiling.

View	Description
Summary	Summary information is presented to serve as a starting point for your investigation. This is the first view you see, and it is opened automatically after the profiling session is over and result file is ready.
Resource Details	A detailed view of a specific resource (for example, a lock), showing all threads that were blocked on it during the application lifetime.
Thread Details	A detailed view of a specific thread, showing all resources (such as locks) the thread was blocked on.
Contention	Call trees that are separated per contention resource. In other words, this view presents a set of call trees, each containing stacks that were blocked on a specific resource.
Processes	A list of inspected processes, where each process has a list of its threads, and each thread is attributed with the number of contentions it experienced, and summarized length of blocked time.
Function Details	A detailed view of a specific function, including functions it calls and collected data.

The Resource Details view, for example, is the following one:

There are several built-in transitions between profiling data views inside VS2010, and they are explained in the article. Let me briefly summarize those transitions through the below diagram, which presents possible performance investigation flows. When you analyze your data, do not feel obligated to use VS2010 views in that exact order or sequence – you can always select any desired view through a drop-down combo box of VS2010 that enumerates all views. The diagram is just a suggestion how that can be done.

The transitions that are enumerated on the diagram are:

1. Move from Summary view to Resource Details view (chart) by clicking a resource name in the Most Contended Resources table

2. Move from Summary view to Thread Details view (chart) by clicking a thread ID in the Most Contended Threads table

3. Switch from Resource Details view to Thread Details view by clicking on a chart label, representing the thread

4. Switch from Thread Details view to Resource Details view by clicking on a chart label, representing the resource

5. Move from Resource Details view to Function Details view by double clicking on a function name in Contention Call Stack panel

6. Move from Thread Details view to Function Details view by double clicking on a function name in Contention Call Stack panel

7. Move from Resource Details view to Contention view by clicking on a Total label of the chart

8. Move from Contention view to Resource Details view through a context menu (right-click) of a resource

9. Move from Thread Details view to Processes/Threads view by clicking on a Total label of the chart

10. Move from Processes/Threads view to Thread Details view through a context menu of a thread

When you open the profiling results file, you see a Summary view that helps you to select a possible investigation direction. Some options to consider here are:

Start in Summary view, detect a contention resource or a thread you want to inspect closely (because it has too many contentions), then explore data through the transitions:
- 1 – to see resource details, or 2 – to see thread details
- 4 and 3 – to pivot between resources and threads details
- 5 and 6 – to see details of function causing the contention
Start in Summary view, use drop-down combo box to switch to Contention view, sort all resources, select one of them, then use transition 8 to get to the resource details, followed by transitions 4, 3, 5 and 6 as required.
Start in Summary view, use drop-down combo box to switch to Processes/Threads view, sort all threads, select one of them, then use transition 10 to get to the thread details, followed by transitions 4, 3, 5 and 6 as required.

[Maxim Goldin]

VS2010: Profiler Guidance (rules) Part 1

profiler1 — Fri, 26 Feb 2010 00:19:22 GMT

The new guidance feature in the VS2010 profiler will look familiar to people who have used the static code analysis tools in previous versions. However, instead of statically analyzing your code, the profiler runs it and analyzes the results to provide guidance to fix some common performance issues.

Probably the best way to introduce this feature is via an example. Let’s assume you have written a simple application as follows:

        1: using System;

       2: namespace TestApplication

       3: {

       4:     class Program

       5:     {

       6:         static void Main(string[] args)

       7:         {

       8:             BadStringConcat();

       9:         }

      10:  

      11:         private static void BadStringConcat()

      12:         {

      13:             string s = "Base ";

      14:             for (int i = 0; i < 10000; ++i)

      15:             {

      16:                 s += i.ToString();

      17:             }

      18:         }

      19:     }

      20: }

If you profile this application in Sampling Mode you’ll see an Action Link called ‘View Guidance’ on the Summary Page:

Clicking on this link brings up the Error List, which is where you would also see things like compiler errors and static code analysis warnings:

DA0001: System.String.Concat(.*) = 96.00; Consider using StringBuilder for string concatenations.

As you can see there is a 1 warning, which is DA0001, warning about excessive usage of String.Concat. The number 96.00 is the percentage of inclusive samples in this function.

Double-clicking on the warning in the Error List switches to the Function Details View. Navigating up one level of callers, we see that BadStringConcat is calling Concat (96% of Inclusive Samples) and doing some work itself (4%). The String.Concat call is not a direct call, but looking at the Function Code View you can see a ‘+=’ call on a string triggers the call.

The DA0001 rule suggests fixing the problem by changing the string concatenation to use a StringBuilder but I’ll leave that up to the reader. Instead, I’ll cover some of the other aspects of rules.

One of the more important questions is what to do if you wish to turn off a given rule (or even all rules)? The answer is to open up the ‘Tools/Options’ dialog and in the Performance section, navigate to the new ‘Rules’ subsection:

Here you can see that I’ve started searching by typing ‘st’ in the search box at the top. This dialog can be used to turn off rules (by clicking on the checkboxes on the left), or to change rule categories to ‘Warning’, ‘Information’ or ‘Error’. The only affect is to change how the rule is displayed in the Error List.

If you have a situation where you are sharing a profiler report (VSP file) with team members, sometimes it might be useful to let them know that a warning is not important or has already been considered. In this case you can right-click on the Error List and choose ‘Suppress Message’.

The rule warning is crossed out and you can choose to save the VSP file so that the next time it is opened, the suppression is shown:

That’s it for now. I plan on covering a little more about rules in a future post, including more details about the rules themselves, how you can tweak thresholds and even write your own rules.

[Colin Thomsen]

VS2010: Profiling In Progress (PIP)

profiler1 — Fri, 05 Feb 2010 01:16:00 GMT

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

profiler1 — Thu, 21 Jan 2010 01:28:12 GMT

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)

profiler1 — Tue, 19 Jan 2010 17:35:59 GMT

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?

profiler1 — Fri, 15 Jan 2010 00:52:50 GMT

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

profiler1 — Thu, 14 Jan 2010 19:07:55 GMT

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:

Error VSP1336 : Could not attach to process ID:1234 notepad.exe. The profiler was unable to start sampling with the specified configuration.

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

profiler1 — Thu, 14 Jan 2010 19:07:00 GMT

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

profiler1 — Fri, 08 Jan 2010 19:33:00 GMT

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

profiler1 — Thu, 31 Dec 2009 22:28:09 GMT

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)

profiler1 — Tue, 29 Dec 2009 22:26:07 GMT

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.

Open the solution with ‘Alt-F, J, Enter’:
Start Performance Analysis with ‘Alt-F2’, which brings up the wizard:
Press ‘Enter’ to choose the default ‘CPU Sampling’ profiling method and move to the target selection page:
Press ‘Enter’ to select the only launchable project in the solution and move to final wizard page:
Press ‘Enter’ to finish the wizard and start profiling:
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

profiler1 — Mon, 28 Dec 2009 22:16:43 GMT

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?

profiler1 — Wed, 23 Dec 2009 00:32:37 GMT

Short Answer:

Profiling Mode	When to use
CPU Sampling	Use this mode to identify methods that consume too much CPU. This mode has low overhead and is well suited for CPU bound applications.
Instrumentation	Use this mode to get exact call count and exact time for each method. This mode is well suited for application that make large amount of external kernel calls (e.g. I/O and Network).
.NET Memory Allocation	Use this mode to identify methods that allocate too much memory.
Concurrency – Resource Contention	Use this mode if you suspect your multi-threaded application is experiencing synchronization issues
Concurrency – Concurrency Visualizer	Use this mode to get a comprehensive view of how your application is utilizing parallelism

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

profiler1 — Mon, 07 Dec 2009 19:50:00 GMT

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]