Visual Studio Team System FAQ

I just recently whipped up a FAQ on the profiler to post as a sticky thread in the VSTS for Developers forum. In the interests of getting this information out to as many people as possible, I'm posting it here as well.

 

Q: What is the difference between the sampling and instrumentation modes of the profiler?

 

A: This is a very common question and understanding the answer will get you a long way down the path to better understanding the way that the profiler works. In a nutshell, sampling profiling captures program state by sampling at specified intervals (such as clock cycles or page faults) and instrumentation profiling inserts probes into your code to catch every single function call made by your program. In general, the best way to profile is to start out with sampling mode to isolate performance “hot spots” in your code where there are performance issues. Then, if needed, you can use instrumentation profiling to instrument just the binaries with performance issues and run shorter, more focused profiling scenarios. This is due to instrumentation profiling producing a large volume of data; if you just start out by just instrumenting everything in your project and running a long profiling scenario, then the size of your profiling (.VSP) files with get out of hand very quickly. By giving you the choice of which to use, and allowing you to switch easily between the two profiling methods, you can selected the method that works best for your specific profiling scenario. 

 

Q: Why am I seeing function addresses instead of function names when I try to analyze a performance report?

 

A: This means that you are not resolving symbols correctly for your performance reports. There can be many causes and solutions for this, so I’ll try to lay them all out below.

 

1. If you are using the IDE make sure that you are serializing your symbols in your VSP file. Check this setting in the Tools->Options->Performance Tools menu. Serializing your symbols will pack your symbols into the VSP file so that you can open it later without access to the pdb files.

2. If you are working from the command line tools you can use the VSPerfReport tool to serialize your symbols into the VSP file. Just use the /summary:all /packsymbols switches and make sure that you either have _NT_SYMBOL_PATH environment variable set or pass in the symbol path with the /symbolpath switch.

3. In the IDE make sure your symbol settings in Tools->Options->Debugger->Symbols are set correctly to pick up all the symbols that you need.

 

Q: Does the profiler work with native code? Does the profiler work with mixed mode code? Does the profiler work with older .NET CLR versions?

A: The profiler works in both sampling and instrumentation modes with both native applications and mixed mode applications. However, we are limited to profiling .Net 2.0 code only so .Net 1.x code (by itself or in mixed mode with native) will not work with the profiler in either sampling or instrumentation modes.

 

Q: Does the profiler support 64-bit code?

A: No, the 2005 release of the profiler does not support profiling 64-bit code. However this functionality will be in future releases.

 

Q: In the profiling reports what is the difference between inclusive and exclusive (time or samples)?

A: It’s a fairly simple concept. Inclusive time means the amount of time spent in this function and all of its subchildren. Exclusive time means the amount of time spent in just this function. The same thing goes for samples. So the function with the highest inclusive time is the function that has the most time between its entry and exit points. While the function with the highest exclusive time is the function that is actually doing the most work.

 

Q: In instrumentation mode the profiler is collecting huge files that take a long time to analyze. What can I do to get more manageable file sizes?

A: First off, are you sure that you need to be using instrumentation mode of the profiler? The sampling mode collects a much smaller amount of data and can be used to pick out specific trouble points to investigate with instrumentation.

 

Also, consider reducing the size or complexity of your profiling scenario. Instrumentation isn’t the best choice to get a “big picture” view of your program’s performance.

 

If you need to using instrumentation and you can’t reduce your profiling scenario, then it’s time to use some of the advanced instrumentation and data collection APIs to reduce the amount of data that you collect. Below I’ve linked to a couple of blog entries that can help you out.

 

http://blogs.msdn.com/angryrichard/archive/2005/01/16/354194.aspx

http://blogs.msdn.com/ianhu/archive/2006/02/07/526835.aspx

 

Q: I’m trying to instrument my signed binary, but now my application is crashing when it used to run just fine. What am I doing wrong?

A: Instrumentation will whack any signing that you currently have in a binary. To get around this, you’ll need to re-sign the binary in the post instrumentation step. From the performance explorer tool window right click on the signed binary that you are instrumenting and select “Properties.” In the properties window use the post-instrumentation event to call sn.exe to resign your binary.

 

Q: I’m a profiler user and I’m looking for some more advanced documentation, samples and tutorial to help me learn how the profile works and how to diagnose performance issues. Is there more material available for the profiler online?

A: There are indeed lots more articles about the profiler online. If I can shill my own product then check out the Visual Studio Team System TechNotes that I wrote. Many of these are expanded versions of blog articles from my personal blog or from the blogs of other team members. Speaking of blogs below are the best blogs to get information about the profiler.

 

Ian Huff’s Blog

Richard Wurdack’s Blog

Steve Carroll’s Blog

John Cunningham’s Blog

Maxim Goldin’s Blog

Eric Jarvi’s Blog

John Lyon-Smith’s Blog

David Gray’s Blog

 

Also, you can check out my basic video demo tutorial that was filmed for Microsoft’s Channel 9 site.

 

Using VSTS Performance Tools to Speed Up Your App

 

Q: Can you tell me some basic steps for collecting profiling data using the command line tools instead of the IDE?

A: When using instrumentation mode:

vsperfclrenv /traceon

vsinstr <your binary>

vsperfcmd /start:trace /output:<output file name>.VSP

Execute your application

vsperfcmd /shutdown

For launching and sampling:

vsperfclrenv /sampleon

vsperfcmd /start:sample /output:<output file name>.VSP

vsperfcmd /launch:<your binary> /args:<your apps arguments>

Interact with your application and exit

vsperfcmd /shutdown

 

For attaching and detaching with sampling:

vsperfclrenv /sampleon

start your app from the same cmd windows that you set profiler env

vsperfcmd /start:sample /output:<output file name>.VSP

vsperfcmd /attach:<PID>

Interact with your application and exit

vsperfcmd /detach:<PID>

vsperfcmd /shutdown

 

Q: Is clock cycles the only thing that you can sample on?

A: The sampling profiler can take samples on several different counters. If clock cycles are not working for you try sampling on page faults, system calls or a specific performance counter.

Q: Can I profile a service with the profiler?

A: Yes you can, but it’s a fairly difficult process and too hard to summarize for a quick FAQ entry. To help you out I’ll point you at Richard Wurdack’s very detailed article on the topic.

~Ian