Concurrency Visualizer: Avoiding Interference During Profile Collection


Those of you who are used to doing performance analysis can appreciate the value of reducing interference between your application and other applications and services running on the system under study.  So far, I’ve been using the Visual Studio IDE to show you how you can collect and analyze a profile.  Since Visual Studio itself can be a resource intensive application, it is sometimes desirable to collect a profile without the IDE’s assistance.  Further, it is sometimes desirable to collect a profile on a system that does not have Visual Studio installed.  For these purposes, the Concurrency Visualizer comes with support in the Visual Studio profiler command-line tools.  The command-line tools allow both launch and attach profile collection.  Here’s how you can accomplish this:


Lanunch Scenario:


1. Open a Visual Studio Command Prompt window as an Admininstrator (remember, ETW-based collection requires high privileges).  The tool is usually found at Start->All Programs->Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio Command Prompt (2010).  The console will have the appropriate paths set up for the tools that we’ll be using.


2. Start profiling and launch the application of interest using the following command (I usually do this from the directory containing the program of interest):


     vsperfcmd /start:CONCURRENCY,THREADONLY /launch:fullpathtoprogram.exe /output:profilefilename


3. Now the application should be launched and you can perform your test.  When finished, if you terminated the application, you can just run the following command to complete the profile collection:


     vsperfcmd /shutdown


4. When the above command completes, you will find the profile file “profilefilename.vsp” in the current directory.  All you need to do now is to open this .vsp file in Visual Studio (Ultimate or Premium) using the File->Open->File menu option.  Just so that you know, there are two other files containing profile data: profilefilename.app.ctl and profilefilename.krn.ctl


Attach Scenario:


1. Find the process id (PID) of the application that you’re interest in.  You can use Task Manager to do that by enabling the PID column in Processes tab using the View->Select Columns option.


2. Attach to the process for analysis using the following command:


     vsperfcmd /start:CONCURRENCY,THREADONLY /attach:<pid of the process> /output:profilefilename


3. When you’re done profiling the usage pattern that you’re interested in, run the following commands:


     vsperfcmd /detach


     vsperfcmd /shutdown


4. When the above command completes, you will find the profile file “profilefilename.vsp” in the current directory.  All you need to do now is to open this .vsp file in Visual Studio (Ultimate or Premium) using the File->Open->File menu option.


If you’d like to collect on a system that does not have Visual Studio installed, you will need to install the Standalone Profiler tools.  There’s a directory on the Visual Studio DVD containing the installer for these tools.  You will need to run this as an admin because it installs a driver.  In addition, the command-line tools require .NET 4.


That’s all you need to collect profiles without the overhead of Visual Studio.  Now go give these a try!


-Hazim


 


 


Comments (2)

  1. Brien says:

    Hazim,

    This sounds great!  

    I’d like to use this in my production environment-  Do you have an estimate for how much performance overhead attaching the profiler will cause?  

    Also, if I am attaching the profiler, does the application need to be running under .NET 4 or is 2.x ok?

    Thanks,

    Brien

  2. _HShafi_ says:

    Hi Brien,

    The runtime overheads are often negligible, but they are a function of your application and the load on the system.  We see higher overheads on x64 systems because collecting stacks is more expensive on those, but we have yet to receive a complaint regarding overheads.  

    The .NET 4 requirement is only for the command-line tools.  You should be able to analyze applications on previous .NET versions based on CLR 2 or higher.

    Happy new year!

    -Hazim