VS Profiler usage in Sampling mode results in generation of VSP file. This file is, naturally, full of samples that were taken during your profiling session. You can get a Properties Window of this file by pressing F4 button:

Today I would like to talk about all different Samples that are reported in General section of this window. Those samples were collected, some of them are used to generate profiler views, and sometimes you may want to understand better the whole picture - how many samples were taken during the session, are all of them in your application, why do you see less samples than you think you should see, etc. This may shed some light on confusing situations, if you try to compare results of VS Profiler with results provided by other tools (for example, when you use Page Fault Sampling, and you compare number of collected samples with a number of page faults reported by performance monitor).

So, all samples collected during the performance session are reported as Total. VS Profiler divides them into the following groups:

• Application - samples taken in context of profiled application
• Kernel - samples taken in kernel mode (system wide)
• Other - samples taken in other applications, that are not proifled
• Overhead - samples taken in profiler runtime

From all the pieces, the Application slice is the one that is used for further analysis. Samples from other group are currently not counted in final results.

Some samples within the Application may be Aborted, if they happen to be taken at "bad" time (for example, during garbage collection). For the rest of samples, VS Profiler detects a call stack chain that resulted in execution of the current function.

Sometimes, profiler cannot detect a full call stack, and detects just most part of it. Those stacks are reported as Broken samples. Both, Broken and full stacks are used for generation of profiling results that are presented in Performance Tools views of Visual Studio Team System.

Trying to summarize all the above, we may present a samples distribution hierarchy in the following way, where only Full and Broken stacks are currenlty taken into account for final results.

•  Total
  • Application
    • Stack Walks
      • Full stacks
      • Broken stacks
    • Aborted
  • Kernel
  • Other
  • Overhead

And you may also get explanation of each line in Properties Window of VSP file by selecting it:

If you want to collect more samples and have more stacks reported within you application, you may either run the application longer, or change sampling frequency (either through /PF, /SYS, /TIMER options of VSPerfCmd.exe command line tool, or in Sampling property of Performance Session in VSTS).

 

We are asked this question sometimes, especially when customers profile real world UI applications. Since it may be really confusing, I’ve decided to post the explanation of this “phenomena”.

 

The Caller/Callee is one of views that are generated by Microsoft Visual Studio Team System 2005 during application profiling. The view is described in details in “Analyzing a performance report in Visual Studio Team System 2005 Part 2: The Function, Caller / Callee and Calltree views” posting or in “Make Your Apps Fly with the New Enterprise Performance Tool” MSDN article.

 

Why do we see callees that sum up with more than 100% of  Inclusive Percent samples?

 

That I can tell you in one word – recursion.

 

Let’s try to analyze the following simple code.

 

void A(bool);

void B();

void C();

 

void main()

{

       A(true);

}

 

void A(bool CallB)

{

       if(CallB)

              B();

       else

              C();

}

 

void B()

{

       A(false);

}

 

void C()

{

       while(true)

         ;

}

 

Actually, this code doesn’t have a pure recursion – no function calls itself. As you can see, the program will block itself having the following call stack:

 

main à A à B à A à C

 

So, function A appears more than once on the stack. Let me refer to this as some sort of recursion. The interesting point here is that function A calls different functions each time (first time it calls B, and second time it calls C)

 

Sample profiling of this application gives us the expected Call Tree view:

 

 

We also get the following Caller/Callee view (showing functions called by A and functions calling A):

 

We see that B and main are callers of A, while B and C are also callees (called by A).

 

But why both C and B in the bottom panel have 100% Inclusive Percent of samples? First, they are "children" of A, so they cannot both have more than A has. Second, 100% + 100% = 200%.  It doesn’t make any sense!

Well, apparently it does. Let’s try to analyze the data we got.

 

1. A calls B, and A calls C. Therefore, both B and C are in the bottom panel of Caller/Callee view as callees of function A. 
2. A, B and C – they are on stack. The only function that has exclusive samples is C, which is at the bottom of the stack (see “What are Exclusive and Inclusive?!” post explaining a difference between Inclusive and Exclusive samples). Therefore, A, B and C all have 100% of Inclusive Percent.  
3. Functions B and C sum up in inclusive samples with more than function A, and they also sum up in Inclusive Percent with more than 100%. Yet it is still true.

 

The above scenario is artificial. Real life scenarios, however, may have some variation of the recursion pattern that we discussed, thus generating profiling data that may confuse at the beginning. I hope this explanation makes it clearer.