Visual Studio 2010: working with the new profiler

I have already had the opportunity to demonstrate how a new summary profiler page makes it easier to find and fix performance problems, but sometimes it takes more effort to search. This time I will delve into my story in another feature of VS2010, which is called Function Details View.

Again, for the demonstration, I will use the PeopleTrax application, which you can download from CodeBox . I have a report that I collected earlier using the CPU Sampling function in the profiler, in which the application heavily loads the CPU (on at least one core).

In this report, I look at the hot trail and see that the People.GetNames method calls the two hot functions StringReader.ReadLine () and String.Trim ().


')
I want to see these demanding calls in my code, so I click on GetNames (highlighted in purple above) to bring up a window with function details.



There are a few things you should pay attention to:

• The title indicates the name of the method People.GetNames ();
• using the drop-down menu, you can switch between “Inclusive Samples%” and “Inclusive Samples”;
• the blue bars show the functions that are called or called by the People.GetNames () method;
• the code of interest is shown with highlighting and annotation;
• in the default view, we may need to push the window apart to see the whole code. Instead, you can use the Split Screen Vertically button and change the view.

Now, on the right side of the view, we clearly see where the resource-intensive calls of the ReadLine () and Trim () functions occur in our code. In addition, we have a table of metrics in the Function Performance Details Details section and some useful links on the topic.

Now, let's take a look at the blue dies. The left die shows methods that call our function. The height of the plate represents the relative cost in the currently selected metric (in this case, Inclusive Samples). Since in this case there is only one calling method, it occupies the entire area of ​​the plate.

On the right is another die that contains the following sections:

• Function Body (87 copies). The height of this section shows the relative number of instances inside the function itself.
• ReadLine (727 copies). This is the function with the largest number of instances (Inclusive Samples). Because of this, the height of this section is the largest.
• Trim (642 copies). The function is the second by the number of copies (Inclusive Samples). Slightly smaller section height.
• and other functions with fewer instances.

Each of these sections (except Function Body) is clickable, which allows you to navigate through calling or calling methods.

Having studied the code, I can’t find a simple solution to simplify it, I can’t control Trim () or ReadLine (), so let's go one level up in the calling functions by clicking on GetPeople (this is the only function that calls our GetNames method - approx. Transl.).



Clicking on GetPeople leads to the transition to the details for this function:



From the code on the right side, we can find out that the two highlighted calls to the GetNames method form 89.2% of the calls (instances). Due to the fact that the loop is being used, for sure the best idea would be to get GetNames calls out of the loop. Those who study the PeopleTrax application know that the first optimization for this application is to cache the GetNames call in the constructor. The next step of the study will be to change the code, collect new information from profiling and compare reports, but I will leave this for you.

Keep in mind: the code level information is only available in the CPU Sampling profiling mode and not available in the Instrumentation mode. Highlighting and annotations are also not available in Instrumentation mode.