[MUSIC]
>> Hey everybody, my name is Sagar Shetty.
I'm a Program Manager on the Visual Studio profiling team,
and in this video I want to go over a tool which should be
perhaps the centerpiece of your profiling toolkit,
the CPU usage tool.
We're going to jump into Visual Studio
here and launch the performance profiler.
I've already done this, but you can
do that with the keyboard shortcut,
Alt F2 or debug performance profiler.
I've selected the CPU usage tool,
which is the tool we're going to be talking about
today, and click "Start".
For this demo, we're going to be using an
ASP.NET core web application.
It's an open source one. Shout out to David Fowler.
It's basically an application that's going over
bad patterns in ASP.NET.
I have a command line script which
is essentially going to hit an endpoint in this application.
Essentially what this endpoint is doing is simulating,
retrieving and returning a JSON response from an external API.
As we're going to see in a minute here,
that's going to generate some good CPU usage data for us.
The script is running and it looks like it's done.
As you can see here in the background,
I'm just going to go ahead and stop collection.
The CPU usage tool has like a swim lane,
a graph at the top.
That was showing the CPU usage over time,
and when I ran that script,
there was a big spike which we're going to see again here shortly.
There's going to be a bunch of views we're going to go over in
the CPU usage tool starting with that swim lane at the top,
and then also a summary page that goes along with it,
which gives you an overview of insights that the tool provides.
Then we're going to open the details view and go
down some of the deeper dive views if you will.
We have a handful of those.
Lots of tips and tricks in this video.
With the swim lane, one general tip is
most of our tools have some graph or swim lane as we call it,
and you can click and drag.
What that's going to do is time filter
the data to that specific range you've selected.
That's a good thing to do because
a lot of times you want to filter out the noise,
maybe filter out some startup process
if you're not really interested in that.
Our tools really do collect a lot of data,
so if you can filter it down to what you really care about,
that can help speed up the tools a lot.
It's just a tip there.
I've selected the range towards the latter half
of the screen where basically we
had that big spike and I ran that script,
and we're hitting that post endpoint.
The data is going to load.
While that's going,
I can show you some of the filters here.
You can filter by thread,
show just my code, native code.
You also have some categories as well which
isn't showing anything because it's loading.
But these can be things like networking, I/O, kernel.
Yeah, this is the summary page.
This is a pretty helpful view.
Basically it has three different components the top functions.
These are functions that are taking up a lot of
CPU time and the CPU
is spending a lot of time calling these functions.
You have the hot paths,
which are essentially pathways in your code.
Functions are called trees,
where your code is spending a lot of time.
Then you have the categories,
so sometimes we'll tag certain functions or processes if they
fall into things like I/O, networking, kernel, etc.
This is a high-level overview of things you might
want to look at certain functions, certain code pathways.
What I'm going to do next is actually click "Open Details" and go
into some of our other views that allow you
to do some deeper diagnostics on your performance data.
Just to reiterate something I said earlier all of
this is time filter to that range that I selected before.
The first view, as you can see, we have five of them.
The first view I want to talk about is actually one at
the bottom here called the flame graph.
For the visual learners amongst this,
this is a really exciting feature.
Basically what this is doing is showing you call stacks visually.
You can see these frames.
This is the Gedit application,
the general process calling an external process,
calling various functions,
and you can see as you go down.
You can zoom into this control and then scroll.
Can allow you to zoom into certain frames.
This is known as the Icicle chart view.
If you want more of the traditional flame chart view,
you can click "Flip".
Whatever orientation suits you best,
you can play around with that.
Like frames, you can see how many times they got called.
As you can imagine, the wide ones are ones
that are at the base of the call stack,
so they're getting called the most of their value is the highest.
Yeah, I just encourage everyone to play around with this.
This is really visual feature and can give
you an idea of where your code is
spending a lot of time and what's being called the most.
Now I want to pivot and talk about some of
the other views we have in the CPU usage tool.
The next one that I'd like to talk about
is the Call Tree view actually.
With the Call Tree view is really showing you
different code pathways that
are taking up a lot of CPU usage time.
One thing that's really nice about
this particular view is we have this hot path function.
That's just essentially highlighting for you with
these flame icons where your code is taking a lot of time,
and like these are
certain functions or code pathways
that you should really take a look at.
As you can see, it's highlighted
this GetPokemonBufferdStringAsync method.
The cool thing with this is I can double-click on it,
and we're in Visual Studio.
We have the full editor capabilities.
We have the source code right here,
and if I just expand this a little bit and scroll down,
we can go back to essentially the source code,
that exact method and look to optimize this.
In this case, this was the function that
was highlighted in that chart as being a hot pathway.
If you can see within the code,
what we're doing is essentially returning
an entire JSON payload into
memory and converting that to the JSON object.
We're essentially reading that
even before converting it to a JSON object.
That's just taking up a lot of memory.
That's why that was considered a hot pathway.
Going back up to the top of the chart again though.
One quick tip with any of our tools.
If you see a chart or a Grid view,
right-click on the column heading.
Sometimes there might be some columns that are
hidden by default that you might want to be interested in.
You can also hide columns that you're not interested in.
Just play around with that because there are a lot of
data points more than sometimes meets the eye.
To talk about some of the data points a little bit.
We have total CPU and self CPU.
Total CPU essentially means essentially at that frame,
that function or service was in
the call stack when that sample was taken.
Self CPU means it was essentially that function was at the top of
the call stack or the very last thing
called when that sample was taken.
Module is just referring to what module library
that function or service I refer to and then category,
like I said before, just general things we tag.
That's the Call Tree view.
I want to talk about some of the other views as well.
We have the Modules view,
which is essentially a high-level pivot
on all the modules in the code,
and just for each module across all the call stacks showing you
what percentage of CPU time did that take up
or how many times was that module at the top of the call stack.
The Functions view essentially is the exact same.
But instead of pivoting by module,
you're pivoting by function.
That's the majority of the views.
The last one I'll just touch on is the Caller/Callee view.
Essentially what this is looking at is putting
a selected function in the middle and
showing you all the functions that are calling it,
and then all of the functions that
whatever you've selected are calling.
If I can get to maybe something a little bit more interesting,
yeah, the Pokemon service is one.
We can see what is calling it.
It seems like the next general package a lot of the time,
and then what is it calling?
It's a variety of things.
Just like before, we can go back to source from this as well.
You can play around with this, go back and forth.
Yeah, those are all of the Detail views basically.
The combination of the Detail views as well as
the summary page give you
a high-level overview how your CPU is operating.
Hopefully that gave you some insight into the CPU usage tool.
Hopefully that was helpful.
Like I said before,
this is going to be probably one of
your main tools in you're profiling tool kit.
I think CPU usage is really core
to a lot of different performance investigations.
If you're interested in learning more about this tool,
definitely check out the Visual Studio blogs,
our Docs page, search the tool we've done other videos on this
in the past that are much more deeper dives if you will.
Yeah, happy profiling. Have a good day. See you.