>> Hey, everybody. My name is Sagar Shetty.
I'm a Program Manager on the Visual Studio profiler team.
In this video, I want to go over one of
the main tools in your memory profiling toolkit,
the.NET Object Allocation tool.
We're going to jump right into Visual Studio,
launch the performance profiler. I've already done that.
You can do that with the keyboard shortcut Alt,
F2 or debug, and then click "Performance Profiler".
We're going to go over the.NET Object Allocation tool today.
I've already pre-selected that and just going to hit "Start".
The app I've prepared for this demo is actually a Win Forms app.
As you're going to see soon,
it generates a bunch of ellipses that represent prime numbers.
If a number is prime,
it'll be filled in green,
otherwise, it'll be yellow.
The app should be coming up shortly.
The tool has been launched.
We have a couple of graphs at the top.
Live objects, the number of objects that
are being created and are allocating memory.
We have another graph with the change
in objects and then private bytes as well.
The app should be coming online soon.
But these graphs are just going to be collecting
some data and once the app is online,
I'll generate some prime numbers. The app is coming up now.
We have a min and max parameter.
I'm just going to click "Generate".
As you can see, it generates and creates this visual here.
The green ellipses represent
the prime numbers and the yellow ones are non-prime numbers.
I'm just going to click "Generate" a few
times and just create some objects and allocate some memory.
Then later on we're going to go back into the report that the.NET
tool creates and then
analyze that data and get some insights from there.
I've clicked "Generate" a few times.
I'm going to go ahead and stop this and let the tool load.
There are going to basically be a couple of
different views we explore.
One is the allocations view,
which goes over various allocation types.
For each of those types,
it shows us how much memory is being allocated.
We can click on those types as you'll soon see,
and then be able to go into the backtraces and
find the code pathways allocating those types.
We're going to look at another view called the collections tab,
which the team has been investing a lot of resources into.
That's going over garbage collection,
which I'll talk a little bit about and
show you where garbage collection is
occurring and some information about that.
Then there's basically like a call trees
and the functions as well,
just showing code pathways that are allocating a lot of memory.
We'll be going over all that in this video.
We're going to walk through all four of these views
here as I mentioned previously, the allocations view,
the call tree, the functions, and the collection,
give you a high-level overview of what each one talks about.
One quick tip with our graphs at the top here,
and this is true across all of
our profiling tools that have the swim lanes as we call it,
is you can drag and click.
What that's going to do is essentially filter down the data in
the corresponding tables at the bottom of
the screen to just that time selected range.
That's a great little tip for you to really
focus in on a specific time slice,
on a specific time range that you're really interested in.
Just because these tools really do collect a lot of data,
which is why sometimes it'll take a little longer to load.
I'm going to flip over to the collections tab.
One thing to call out as well just with the graphs is,
if you notice this object Delta graph in particular,
they're green bars and then these red bar,
so green bars are adding objects,
more objects are being created.
As you can see here, these red bars,
as it indicates going downward,
it's a negative change.
These red bars actually indicate where
garbage collection has occurred.
Garbage collection is like a product of the.NET run-time.
Basically, it's almost like
this automatic memory cleaning service that we have.
It basically combs through
the stack and looks at objects that maybe
haven't been used in a while and are holding onto
a lot of memory and cleans that up for us.
The collections view, it's loaded.
I want to speak to this a bit.
Gives us some information at
every single point that garbage collection is occurring.
If I drag this up a little bit,
we can see all the garbage collections
that occurred in the time range 1-6.
We can see the generation for garbage collection.
There are various versions of GC in terms of generations.
Some objects are held on for longer periods of times,
and so they're promoted to later generations.
The collections view really gives us a good overview on
all the different things happening within
garbage collection at that particular point
in time. Another quick tip.
This table has a lot of data,
and if you right-click on any of these column headers,
you'll see the full range of data points you can get.
Definitely encourage everyone to play around with this.
You can definitely show more columns,
hide columns you don't want, play around with that.
This is the GC view in a nutshell.
Want to flip the table a bit and
talk about some of the other views as well.
This is the allocations view.
It has two halves to it.
On the left half is the different allocation types.
It has a bunch of different data structures,
classes, objects that are involved.
Basically, bunch allocation types.
If we double-click on a specific type,
what we get on the right side of
the screen is essentially a backtrace,
which is essentially showing us in our code where
those objects of that type are being allocated.
This is going to load. What I want to
show here is we have this ellipse class,
this type that's being allocated a lot.
I want to go back to the source code where that's being
allocated to highlight inefficiency in our code.
This backtrace is going to load
and it's essentially going to show us in
our code where this ellipse class is allocating a ton of memory.
As I mentioned before,
with any of our charts,
really play around,
right-click on a lot of the column headings.
You might find columns that are not
shown by default that you'll be interested in.
The backtrace has loaded.
As we can see here,
we have an inverted call tree,
and so the leaf node is at the top.
This generate primes function seems interesting.
It's doing quite a lot allocations in bytes.
To go to source, it's really easy.
You just right-click and then click "Go to Source".
That's going to bring me to source.
It's great that we're right here within Visual Studio.
We have access to the source code.
I can see within my generate primes function
we have this long for loop.
Within that for loop,
which is running for
all the numbers that I wanted to generate in that visualization,
I'm creating a new ellipse object every single time.
That's where a lot of memory is being allocated.
That's a quick sneak peek in how you can go back to source.
To quickly touch up on some of the other views,
we have the call tree and functions view as well.
But basically, in summary,
what they do is show you the call tree and
the different call stacks that occurred in your code
and where all the memory is being allocated.
The functions view pivots by a function level across all
call stacks where your code is allocating a lot of memory.
In conclusion, that's the.NET Object Allocation tool.
It's a great tool to have in your memory toolkit.
It really shows you a lot of insights into
garbage collection with the collections view.
It allows you to filter by a variety of different parameters,
whether allocation type or by function.
You can ultimately get back to your source code
and figure out where to have optimizations.
Hope that was helpful.
Taught you a little bit about one of our profiling tools.
We're generating tons of content on
the Visual Studio YouTube sites and on
docs and blogs and all of our tools.
For more information, go check out some of those sites as well.
Happy profiling. Take care.