mgoldin's blog

Team System MSDN Public Chat

mgoldin — Tue, 18 Oct 2005 04:57:00 GMT

Visual Studio Team System for Software Developer & Visual Studio Team System for Software Testers

When: Wednesday 10/19/05 @ 10am PST

What: Join us to discuss the Profiler, Test Tools (Unit, Generic, Manual), Web & Load Testing, and Code Analysis (FxCop & PREFast). We have questions for you, will answer questions from you, and will chat about the exciting new technology.

Where: http://msdn.microsoft.com/chats

Total, Application, Kernel, Overhead, Other samples - what are they all about?!

mgoldin — Fri, 05 Aug 2005 21:07:00 GMT

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 profiled
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).

Multiple profilers of managed code on the same machine. Why it is bad?

mgoldin — Tue, 26 Jul 2005 21:05:00 GMT

It may happen that when you try to attach Visual Studio profiler to a managed application, you get the following error:

Error VSP1336 : Could not attach to process ID:1234 MyProcess.exe. Wrong setting of COR_PROFILER environment variable in target process. Please use VSPerfClrEnv.cmd to set environment variables correctly.

You follow the instructions precisely, use VSPerfClrEnv.cmd properly, and it doesn't help. What is wrong?

The next question I would ask you is: "Did you install other profiler on your machine?" If yes, try to uninstall it, reboot the machine and use VSPerfClrEnv.cmd again.

The issue here is that usage of .NET profiling services is bound to the COR_PROFILER environment variable, and each profiler sets it to its own value. Having more than one profiler in field may cause a conflict, where profilers "fight" with each other for the right to set this environment variable. If process is created having this varialbe set by a different profiler, Visual Studio profiler detects this and generates the above error.

Why function callees sum up with more than 100% in Caller/Callee view?

mgoldin — Tue, 28 Jun 2005 09:17:00 GMT

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.

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.
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.
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.

Let me introduce myself

mgoldin — Mon, 27 Jun 2005 19:50:00 GMT

Hello,

I am Maxim Goldin, and I am a developer in Microsoft Visual Studio Team System 2005. More specifically – I spend all my working hours developing a profiler, which is a part of VSTS. I joined Microsoft in June 2003 after serving Intel Corporation in Israel for 8 years, and I am originally from Russia.

Profiling an application might be a non-trivial task; this is where I might and wish provide some help – either in running the tool, or understanding the results. I will be also grateful for any comments / suggestions about our tools – how to make them better and more user friendly, what are problems that you experienced with them, what functionality would you like to see there. Oh, and – just to mention it – I will not object to get positive comments as well J !

This is my first attempt to write a blog, and I find it quite exciting experience.