Profiling From the Command Line

  • Makale

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

  • Anonymous
    July 29, 2004
    Thanks much!!! I'll give it a go...
  • Anonymous
    August 06, 2004
    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.
  • Anonymous
    August 06, 2004
    The comment has been removed
  • Anonymous
    August 06, 2004
    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
  • Anonymous
    August 06, 2004
    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
  • Anonymous
    August 06, 2004
    Did you recollect the data again as well or are you still using the old VSP?
  • Anonymous
    August 06, 2004
    Yes. Did it all from scratch.
  • Anonymous
    August 06, 2004
    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.
  • Anonymous
    August 06, 2004
    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...
  • Anonymous
    August 06, 2004
    The comment has been removed
  • Anonymous
    August 06, 2004
    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.
  • Anonymous
    August 11, 2004
    Got it to work! The part I was missing was:

    regsvr32 VSPerfCorProf.dll
  • Anonymous
    January 24, 2008
    The comment has been removed
  • Anonymous
    January 18, 2009
    PingBack from http://www.keyongtech.com/1194309-profiling-in-vs-2008-a