Profiling From the Command Line


General Tips:



  • /? is your friend.  Until formal docs are written, you can see all the parameters that each command-line tool accepts by calling the .exe with the /? option. 

  • Do yourself a favor and set up the PATH environment variable.  The “Visual Studio Command Prompt” shortcut has not yet been updated in CTP to include the profiler tools in the path. Sorry.  So you’ll need to add the following path yourself: \Program Files\Microsoft Visual Studio 8\Enterprise Developer Tools\Performance Tools
    WARNING: When you add this to the path, especially if you are using tab completion that automagically adds quotes, be sure that all quotes are removed before you set it. Unfortunately, quoting the path can cause Windows to fail to load DLLs in there that the profiler tools need.

  • For advanced users who intend to control instrumentation at the source code level, vsperf.h is included in the …\Performance Tools\PerfSDK directory, and of course this must be in the INCLUDE path when you build.

Simple Walkthrough for Command-Line Profiling:


Decide what type of profiling you’ll use.  Sampling is generally more appropriate for long-running scenarios that generate loads of data.  Instrumentation (trace) profiling is more for when you’re ready to narrow down to smaller focus areas and get the fine granularity. Then



  1. Instrumentation only – use vsinstr.exe to in-place instrument your .exe.
    Sampling only – set the environment for managed sampling using vsperfclrenv.cmd (some tips for doing that were blogged about here )

  2. Start the monitor with vsperfcmd.exe. The -start:sample corresponds to sampling and the -start:trace option corresponds to instrumentation.  An example for trace profiling might be:  vsperfcmd.exe -start:trace -output:MyDogSlowApp.vsp

  3. Run your application (the monitor will be collecting the performance data at this time).  For example, run MyDogSlowApp.exe from the command line.

  4. Shutdown the monitor with vsperfcmd.exe -shutdown (this will also trigger generation of the .VSP file you specified as the output file at start time that will contain the collected data)

  5. Generate a report from the now available .VSP file using vsperfreport.exe.  For example, vsperfreport -summary:all will generate all the different types of reports in .CSV format.  Generation X’rs may enjoy the -xml option for adorning their data with angle brackets.

Hope that helps, keep the feedback coming! 


[ejarvi]


Comments (16)

  1. Adam says:

    Thanks much!!! I’ll give it a go…

  2. Adam says:

    This seems to work for me. However, I’m not able to get the method names to show up in the reports. The *_FunctionSummary.csv report contains only addresses under the "Function Name" column. I’ve tried using the -symbolpath switch with no success (the current directory contains all the PDB’s):

    vsperfreport MyApp.vsp -summary:all -symbolpath:.

    The one suspect message I am getting when running vsperfreport is:

    Warning VSP2340 : Managed code profiling DLL was not loaded.

    Environment variables may not have been set.

    A report file MyApp_Header.CSV is generated.

    A report file MyApp_FunctionSummary.CSV is generated.

    A report file MyApp_ModuleSummary.CSV is generated.

    A report file MyApp_CallerCallee.CSV is generated.

    A report file MyApp_CallTree.CSV is generated.

    A report file MyApp_ThreadSummary.CSV is generated.

    Any ideas?

    Thanks in advance.

  3. steve carroll says:

    For managed profiling from the command line you need to set up several environment variables. We provided a script called VSPerfCLREnv.cmd that should be included. Make sure you run this command before you profiling run or we won’t be able to resolve any managed symbols!

    I’m assuming your app is Managed. Is that correct?

  4. Marc Popkin-Paine says:

    If it is .Net Code as Steve is suggesting, you can check out our blog posting on how to set up the environment for profiling managed code. The environment settings are needed for symbol resolution for managed trace profiling and managed sampling (only when attaching).

    Good luck and let us know if this fixes the problem.

    Here’s the blog link:

    http://blogs.msdn.com/profiler/archive/2004/05/25/141843.aspx

  5. Adam says:

    Thanks for the quick response. Yes, it is managed. I just tried:

    vsperfclrenv /traceon

    Enabling VSPerf Trace Profiling of managed applications (excluding allocation profiling).

    Current Profiling Environment variables are:

    COR_ENABLE_PROFILING=1

    COR_PROFILER={b21542ea-98d7-4704-a4c9-73fd1e54203d}

    COR_GC_PROFILING=0

    It did not seem to make any difference. I am still getting the "Warning VSP2340 : Managed code profiling DLL was not loaded." when I generate the report.

    This is my path:

    C:Program FilesMicrosoft Visual Studio 8Common7IDE;

    C:Program FilesMicrosoft Visual Studio 8VCBIN;

    C:Program FilesMicrosoft Visual Studio 8VCVCPackages;

    C:Program FilesMicrosoft Visual Studio 8Common7Tools;

    C:Program FilesMicrosoft Visual Studio 8Common7Toolsbin;C:Program FilesMicrosoft Visual Studio 8SDKv2.0bin;

    C:WINDOWSMicrosoft.NETFrameworkv2.0.40607;

    C:WINDOWSsystem32;

    C:WINDOWS;

    C:WINDOWSSystem32Wbem;

    C:Program FilesMicrosoft Visual Studio 8Common7Tools;

    C:Program FilesMicrosoft Visual Studio 8Enterprise Developer ToolsPerformance Tools

  6. Eric Jarvi says:

    Did you recollect the data again as well or are you still using the old VSP?

  7. Adam says:

    Yes. Did it all from scratch.

  8. steve carroll says:

    Hrm. That’s confusing. We have a -debugsymbolpath flag in the new version that helps to track down symbol loading problems, unfortunately that isn’t in the version you are working with.

    Do you get symbols for any managed apps at all? Can you try creating a trivial hello world console app in the UI, and profile that with instrumentation in the UI. I want to try to rule out a bad CLR installation.

  9. Adam says:

    I’m sorry, I should have mentioned this before. I’m trying to use the May CTP "Performance Tools" w/ Beta 1 environment. That may be the cause for the problems (though I thought things were close enough to work).

    This is why I can not do this from the IDE. I’ll try the same steps w/ an "Hello World" app. on a May CTP machine I have and see if that works…

  10. Marc Popkin-Paine says:

    If you get the IDE to work for the scenario you want then that would be preferable because it handles all of the confusing environment settings for you and you wouldn’t have to worry about any of that. Plus, viewing reports in the UI is much easier on the eyes.

    If that doesn’t work and you are still getting the warning message about the managed code dll on the command line, let’s make sure that everything is being done correctly (ie the target app needs to be run with the correct environment, not the profiler…a common mistake).

    Maybe try the command line approach with a simpler managed app to make sure that things are at least working.

    vsinstr <application>

    vsperfclrenv /traceon

    vsperfcmd -start:trace -output:foo.vsp

    <application>

    vsperfcmd -shutdown

    vsperfreport -summary:function foo.vsp

  11. steve carroll says:

    oof. yeah. May CTP bits + Beta 1 is not going to work.

    In somewhat more positive news, the next CTP is not too far out and that will be more complete with much more recent core bits.

    sorry man. It might work for native code though.

  12. Adam says:

    Got it to work! The part I was missing was:

    regsvr32 VSPerfCorProf.dll