>> In part 1, we talked
about profiling, what it is, and when and
why you should use it. Now, it's time to pick the right tool to use in
Visual Studio to do so. So how did we do that? Find out in part 2 of this jam-packed episode
of Visual Studio Toolbox. [MUSIC] >> Hi everyone. Welcome
to Visual Studio Toolbox. I'm your host, Leslie Richardson, and I'm joined once again by Profiling PM Sagar Shetty for part 2 of our series on
profiling. Welcome, Sagar. >> Thanks for having me,
Leslie. Good to be back. >> Great. Last, in part 1, we talked about just a generalization about what profiling even is, when you should use it,
why you should use it. At this point, I don't know
about how to use tools. What are some of the
tools available to us in Visual Studio that we can use to fulfill our profiling dreams? >> Well, you're in
luck, Leslie, because this episode is all about
tools and when to use them. So to kick things off, within Visual Studio at a high level, there's two sets of tools that
you can use for profiling. The first one is the
Performance Profiler. So basically, the Performance
Profiler is a suite, you can think of it as a
standalone set of tools that gives you the opportunity to do some really in-depth
performance analysis. You can use multiple
tools in conjunction. How exactly do you use these tools and where
do you go to find them? We touched on this a little bit in the last episode and
I'm actually going to screen share and go into
Visual Studio here. Yeah. I'm in Visual Studio and to get to the
performance profile, there's a couple of different ways. The keyboard shortcut is Alt-F2. You can also go to "Debug", "Performance Profile",
and that will also show you this keyboard shortcut here. We get to this kind
of a landing page. Like I was saying before,
it's essentially a suite of performance tools that
allows you to really drive your performance investigation for whatever the nature
of your investigation is. So I thought we just go
through here and talk about all the tools at a high level
and when you might use each one. Excited to announce that we have
some newer tools up and running. Let's start with at the top
here, the .NET Async tool. Leslie, I know you're
really familiar, we joked last time
about asynchronous code and digging into asynchronous tasks. We have a relatively new tool
here at the .NET Async tool. Basically, what this
allows you to do is really investigate the nature of your asynchronous code and
your asynchronous tasks. What this tool is going to show you is the different asynchronous tasks, the start, the stop time, the duration of when
these tasks take place, how the overlap is occurring, and give you some more insight into how your asynchronous
code is functioning. If you're doing a lot with Async, this is definitely
a tool to checkout. Like I said, it's relatively new. >> That sounds great since
like as is whenever you're trying to diagnose Async code, it's not the easiest. >> Yeah. >> Yeah. >> Yeah. Really,
something we wanted to do here was increase that visualization. Because like you said last time,
it's not necessarily easy to diagnose or track down where
the issues are happening. Again, we're bringing
some more visualization to the Diagnostics hub, and this is something that
we didn't have before, so we're really excited for that. The next tool is the
.NET Perf Counters tool. This is actually a brand
new tool shipping in 16-7. So the version of VS I have up right now is
actually a preview build, its 16-7 Preview 3. So if you're using, and I'll
go ahead and plug this, like I'd highly recommend
customers to start testing. This is an external preview build so customers have access to this. You can go ahead and install
that right now and go ahead and start playing around
with that .NET Perf Counters tool. But basically, this tool is a tool that helps visualize and
support .Net-Counters. What are .Net Counters?
Basically, they're a way to look at a set of metrics that are your initial start to your
performance investigations. So these are metrics like
exceptions per second, maybe some information around
garbage collection, CPU utilization. Up until this point,
the primary way to visualize and consume these metrics
was through the command line. So what we've done is brought
some of that experience into Visual Studio to give you some more deeper
visualizations and insights. We have a table to give you some more information about
these metrics as well. We're really excited about
the .NET Counters tool, which should be coming to everyone in GA in the next month
or so, early August. Yeah. That's the .Net
Performance Counters tool. Moving along here, the next
tool is the CPU Usage tool, an absolute staple in the
Performance Profiler. We talked about in
the first episode how CPU investigations and that bucket of CPU usage and utilization issues is a common
scenario that comes up. The CPU Usage tool is really
the driving force and the go-to tool to do
CPU investigations. Basically, this is
all about seeing how CPU time is being spent during
your program's execution finding functions and modules
that are taking up a lot of your CPU time and taxing
your CPU the most. That's a very, very common tool and we're going to talk about
that one more and how to optimize that little bit later on. >> That's not easy to
track down sometimes. >> Yeah. There's
definitely a lot you can tweak with the settings there and
we'll definitely go into that. Next tool, also new-ish, but it's been around
for a little bit, is the Database tool. The Database tool is
essentially just looking at all the queries your
application is making and your applications in many
cases are making quite a lot. This is giving you that sense of what are all the queries my
app is making and essentially, how long are they taking? This is something really
good to point out here. Going back to VS, you'll notice that there are check boxes
next to a lot of these tools. Something I want to stress is that you can use multiple of
these tools in conjunction. For example, using the Database tool and the CPU Usage tool
might be interesting because the Database tool
is showing queries that your application is making and
one might be taking a long time. Then using the CPU Usage tool, that gives you more into
expensive operations and what functions that
I need to manipulate to optimize that query
if that makes sense. I definitely want to stress
this is not just a one-off, you use one tool at a time. You have the checkboxes here. You can see that many of these
tools can be used in conjunction. So that's a good thing
to keep in mind. >> What's the catch? Is there a
performance hit when it comes to the time it takes to diagnose all of this with the more
boxes that you check? >> Yeah. You got it. Definitely,
there's a little bit of that and we try to safeguard our
customers a little bit. As an example, I checked the
box the Memory Usage tool here, and you notice a lot of
these other box is gray. We'll touch on this in the next episode when we're
interacting with the command line. You can technically run all of
these tools in conjunction. But within VS, we
try to safeguard our customers a little bit and say that for certain tools
that are really, really expensive, we
try to run them in isolation just so you don't
have a degraded experience. But yes, even with some
of these other ones, I still would recommend when you
can run multiple, go for it. If you're running into
deep performance issues, sure, maybe turn it
back a little bit. But it's great that you can really run a lot of these
tools in conjunction. As we continue to develop the
Performance Profiler and update it, we're going to try to make a better and better
seamless experience where playing with multiple tools
that once really gives you those deep insights and
connections between tools. >> Really cool because
I think for a lot of people diagnosing your code
is already a tedious task, so if you can speed it up
and make it more efficient by having multiple tools going on
at the same time, then why not? >> Absolutely, and especially sometimes when you're starting
off your investigation, you don't necessarily know
exactly where the problem lies, is it a memory issue,
is it CPU related, is it something database async? Being able to fire off
a lot of these tools at once helps you get
going like you suggest. So continuing on, I believe we
just talked about database. So events viewer, also
relatively new tool. Essentially, this is looking at
ETW and NetTrace based events, things like module loading, thread starts, system
configuration, and essentially, looking at a ton of different events and their corresponding properties. This allows you to do all
things like looking at logging messages and exceptions
and things of that nature. Really getting some more
events into the Diag Tab, which wasn't necessarily
there before. Then lastly, under the available
tools section for now, and just to point out, so available tool is just
talking about what's relevant for this
particular app I have up, we have other tools that in this
situation are not applicable, but they are tools and
the diagnostics app. We're essentially showing
you for any app you have, what are the relevant
tools that you can use in that particular situation. Just wanted to make that delineation. But the last available tool in this situation is Memory Usage tool, another staple in the
performance profile. This is actually one of two memory-related tools we have
in the performance profile, the next one I'll talk about after, but the Memory Usage tool is really good for a lot of
different scenarios. I think one of its defining
characteristics is that it can be used in .NET Core managed scenarios, it can also be used in
native scenarios as well. So it can be used in quite
a variety of app types, mixed-mode apps as well, that mix both native and managed, and so it's really good for
tracking down memory leaks, code pathways that are allocating
a lot of memory, and etc. Segueing into the
other memory profiler, which is the .NET Object allocation tracking tool,
a bit of a mouthful, but I would definitely
recommend you check it out, especially if you're working on
.NET Core applications absolutely because we've actually been
updating this tool quite a bit. You've got quite a
bit of an overhaul in 16.5 where we added some icons, some killer icons in there, fixed up the backtrace a bit so
that it's essentially easier. The key with this tool again, also, is really figuring out what
are the code pathways that are allocating a lot of code and what in this case, .NET objects are
taking up a lot of code. It's really geared towards, for you as the user, figuring out what are the actionable
and tangible areas of my code I can actually impact in order
to fix my memory problems. Also with this tool, you get some nice insights into
garbage collection as well, so that's definitely
something to think about. >> What do you say, the
Memory Usage tool would be good for the C++ scenarios, which most people are familiar with
revolving around memory leaks? >> Exactly. I really think of that
one as more of the native tool, but for the managed
scenario is exactly, I would definitely recommend
checking out the .NET alloc tool, especially with some of the
updates we've been doing. >> Cool. >> Rounding up the
street here. You've got the Application Timeline
tool and instrumentation. Application Timeline,
this is really looking at XAML applications and
improving the performance. They're things like improving
the time spent rendering frames, servicing networks for
your different XAML apps, not one of the more
commonly used tools, but it's definitely
there and really there to tweak XAML applications
in particular. Then lastly, instrumentation. This is essentially injecting code bits to better understand
your code and certain tasks. We have two main data
collection methods within the Performance
Profiler: One is sampling, which is taking some data points at periodic intervals and
aggregating that together. But by definition
with a sampling rate, there's some granularity there and you lose some of that data in-between certain
points and certainly, you can increase sampling rate. But instrumentation essentially
is injecting code to get a very very detailed set of data at a very fine-tuned
point, like timing interval. Essentially, you're injecting code to better understand various operations, so just reading the
writing to disc and etc. Again, not one of our more commonly
used tools, but it is there. So that's the Performance Profiler, it's a suite of non-debugger
integrated profiling tools that really shows the
performance that's most close to the end-user experience, and that's our first set. We do have a second set though. >> That's a lot of
tools that I'm sure a lot of people were unaware of. Is all of this enterprise
exclusive or can anyone use it? >> Yeah, so this is
available to everyone, so community, professional
enterprise, it doesn't matter. It's available with all those cues. >> Sweet. >> Yeah. The second set of tools
is the Diagnostics Tool window, and I think you'll really
appreciated this, Leslie, because the key thing here is that this is integrated
with the debugger. With the Performance Profiler, what we're looking at is more
of a standalone set of tools. With the Diagnostics Tool window, we're going to look at a few
things that's really cool, where it's really playing nicely
with the debugger itself. I'm just going to close out
of this diag session here. Going back to Visual Studio, we've got this app in the background, we'll talk about this a little
bit more here in a second. I'm going to launch this app and
I'm going to start debugging. A few different ways to do that, you can hit this star
green arrow here, you can hit "F5",
you can hit "Debug", "Start Debugging", I'm
just going go ahead and hit "F5" out of habit. Let me actually stop debugging here because this actually
brings up a great point. Basically, what this is saying here is that we're
in a release build, so what I want to do is switch
this back over to a debug build, and this is actually really
important to bring up. To use the debugger in the most
efficient and optimized sense, you want to be in debug mode, and it turns out that that's
great for the debugger, and we're going to do this here, but it actually has a bit of an opportunity cost in the
sense that the debugger has certain operations that degrade the performance of
the performance data, and it doesn't necessarily show you the most accurate performance data. That's not to say that these
tools aren't relevant, we'll talk about this
more in the next section when we talk about when
you would use each tool, but just keep that in mind. For now, let's just
continue and we'll revisit this point just to have the
best debugging experience. Basically, in this app we
have going on here it's a web application that's going over a ton of different ASP.NET scenario. So looking at the app here, we've got retrieving and
returning a JSON response, HTTP client to retrieve
a JSON response, just some async operations, etc. Going back to VS for a second here, what I want to bring
your attention to is the Diagnostic Tool window. >> That window that a lot
of people like to close. >> Yeah, exactly, and if you do close it and you
want to bring it back up, I would bring your attention
to the search bar, and all you have to do is type in Diagnostic Tool window and
then you bring it back up. >> As a debugging girl,
don't sleep on this window, it's a really cool window, there's a lot of great
things in there. I especially like the
Events Tab personally. >> Yeah. You heard it here folks,
don't sleep on the window. There's four tabs here, and we'll come back to
the graphs in a second. But basically we've got the summary, which is showing an overview of different events that
might be going on. We have the memory usage pane, so we can take memory snapshots. We have a CPUs usage record profile. Let's walk through some
of the other main tabs. Events, we don't have a whole
lot going on right now. We just started our apps, so we've got some basic output. I'm going to run a few
of those scenarios we saw on the web app in a second, so we'll get some more
interesting output here. Memory usage, we haven't
done anything again yet, so I'm actually going to go ahead and take a snapshot just so we
get a bit of a baseline. This will come back into
play a little bit later. As we have some basic
information on the time elapsed, some of the objects
we have allocated, and how much memory they're
taking up until this point. Then CPU usage, we need
to set some breakpoints, which I'm going to
do here in a second. But once we do that,
we'll be able to get some more information on the cost of specific operations
in-between breakpoints when our application
is in a break state. But for now, we haven't really
done a whole lot with the app. So I'm just going to
go back to the app, hit a few buttons, do my thing, and then we'll get
some more information. I'll just make a few of
these JSON calls here. Again, this is just a web app, just going over a
few basic scenarios. I'm going to spam that a few times, I'll make a few more requests. This is just going to populate
some more interesting data. >> Loving the Pokemon resources. >> Yeah, exactly. We'll do that a few times. We should have at least a little
bit of data to work with here. Now I'm going back to VS. If we go to events,
hopefully, we see a lot more. We see that a controller is invoked. We have the big JSON content three, we have an HTTP request, we have get. We have a little bit more events now, as we can see after I actually operated a little bit
more within my app. This is going to give you
some basic information on what's happening here. It's also reflecting the summary. Memory usage, we took that snapshot before we
did anything with the app. Let me take another
snapshot here again. What we'd expect is, so we have way more objects. They're taking up way more memory, and we have this difference here. What's really cool about this is
if you click on this, for example, this is a diff report, and it's
going to open up this table here. Now you're getting a little
bit more insight into what's going on under the hood. What's cool about this
particular report is, this is what we call a diff
report or a comparison report. So you have the
different object types that are allocating memory over here. To the far right, I can just start with the
standard report actually, perhaps that might be a little
bit more easy to grasp. At this particular moment
in time, for this snapshot, you have the different counts for
those particular object types, like the size of how many bytes they are taking
up and the inclusive size, so everything within that category. With the diff report, what you're
doing is you get those columns, but you're also getting the comparison compared
to the first snapshot. So we can see exactly how
much the difference was between snapshot one and two. When we had just started
our app and then when we did a little bit
more exercise to our app, and we can see the
exact difference of exactly how much more
memory we allocated. I want to go ahead and plug here, and I'll probably plug
this a few times. You've got docs that go into
these reports a lot more, so we'll definitely be
linking that below. That gives you a much
more thorough explanation into a lot of these columns, if you want to go back
later and play around. But that a high level is what we're doing with
these memory reports. The last tab I wanted to talk
about is the CPU usage tab. Something we alluded
to before, Leslie, is that this window is
sitting within the debugger. We know the debugger has got
tons of different tools, and perhaps there's nothing more
fundamental than the breakpoint. What I want to show here is
how we play with both worlds, both the debugging world
and the profiling worlds. To do that, I'm going to go
into my code little bit. I'm going to go to this JSON
output controller file, and I want to set some breakpoints. So on the web app, when I was clicking those buttons, it goes back to these
particular tasks. What I want to do this time is
when I click one of those buttons, I want to trigger one
of these breakpoints. I've set a few here around this task, and now we're going to
go back to my web app. Just went to the top here,
and I found a scenario. This scenario we want to click. So I'm going to click on this and it's going to hit this
first breakpoint. Now, I'm going to continue and
run to my second breakpoint, and now we see the
CPU usage loading up. Let me go ahead and maximize this
just so that everyone can see. >> Good old pie charts. >> Good old pie charts. In this case, this is looking at a
top five categories. In this case, since we're
looking at CPU usage, just looking at categories
that are taking up a lot of the CPUs, bandwidth basically. So taking up a lot
of CPU utilization. Within this view, and you get a similar view within the
performance profiler as well. These tools are pretty
similar between both. But at a high-level, what we have is some functions of interests that we
should be looking at. Taking up a lot of the CPU, like a service like this taking
up 50 percent of the CPU, and also some hot path. So hot paths are essentially areas of code that you should go
back and really look at. Because they are areas
that are in this case, taking up a lot of the CPU usage. So you have a few
different looks here. You have the functions view, which is showing you specific
functions to look at, and then also the scenarios of how you drive down into
the code to get there. >> So having this
tool is cool enough, but on top of that, Visual Studio will help you
operator by just giving you the critical areas that you
might want to check out? >> Absolutely, and then
that's really important. Because at the end of the day, we want to make it as
easy as possible for customers to figure out not
just what the problem is, but where it is, and
how they can fix it. That's exactly what
we're seeing here. Like I said, again, plugging
the docks, we'll link them, and there are some more reports that these can go into in more detail, that show you a ton of
different other scenarios too. But yeah, that's the
diagnostics tool window. As we saw there, playing a little
bit with the debugger as well, directly the breakpoints were
profiling information here. So kind of two worlds
coming together. >> Yeah. One question I
had was in the editor, when you place the two breakpoints
and you ran F5 and everything, there is some inline
information that tells you how many milliseconds
have passed and between the time of the first breakpoint
to the second breakpoint. I think that's an
enterprise exclusive. But if you click on that, does that lead you to the same window just as another entry
point that you can use? >> Let me just make sure
I understand, Leslie. So we're back in the code here, we're looking at this particular task and you're asking
about this perf tip, if I click on this, is
this enterprise only? Yeah, I believe this is
enterprise-only. Yes. >> Cool. But if you do
have enterprise though, it seems like a good way to segue way into that diagnostics
tool window immediately, right? >> Oh yeah, absolutely.
One more thing I wanted to bring up at the
diagnostics tool window. Going back to the
swimlanes a little bit. So swimlanes I'm referring
to these graphs up top. One of the critical aspects to the swimlanes is that
you can time filter, so you can select the time range. Here I already have a
time range selected, I can modify that to whatever I want. The important thing here is that when I select a
new slice of time, it's filtering my data
across all tools, so that particular time range. So if you're trying to do some
analysis across multiple tools, memory usage, CPU usage, etc, you can get that time slice
for exactly what you want, and then go back and investigate the data across all tools
for that particular time. Just wanted to make sure I
threw that in there as well. >> What's the order of
operations on that? Can I select a segment
of that swimlane, and then go into the
memory usage tool and run that and it will
automatically filter it? >> Yeah, so you have
some flexibility here. If you've collected the data, you can always go back and
just time filter after that. >> Cool. >> Yes, that's a high-level overview of the tools available
within VS. We talked about the performance profiler being more
of a suite of standalone tool, the diagnostics tool
window being much more integrated with the debugger. >> So for me, since I find myself
debugging more often than not, I'd probably be looking at the
diagnostic tools window more. You already touched
on it a little bit, but where's the
circumstance where I'd want to pivot and use the
performance profiler? >> Yeah. >> Profiling needs. >> Absolutely. One of the things
that we touched on earlier is, when we went to the debugger and
used the diagnostics tool window, we switched from the release
build to the debug build. Coming back to that point, I would highly recommend
when possible, customers use the release build
and performance profiler. The reason for that is, that data is the most
precise and accurate. The release builds provide optimizations like in-line
functioning calls, pruning on used code paths, and storing variables in ways
that the debugger can't. The debugger has its
own unique operations in terms of how it
looks at exceptions, and loads modules that is
critical to how it functions. Unfortunately, because of that, it changes the
performance time itself. When possible, try to use release builds and try to use the
performance profiler, because it essentially
gives the exact or most precise data that your customers are
going to end up seeing. Furthermore, for
different scenarios like external performance problems
like file I/O or network issues, you're not going to see much
difference between the two tools. Either maybe fine again
if you can help it, probably use the
performance profiler. For CPU intensive calls, sometimes there could be
a significant difference in performance between the two. Definitely check to see if these issues exist in
release builds first again, because that's going to be most closely what your
customers are seeing, so that will also be the
performance profiler. I guess the real thing with the diagnostics tool
window though is that, if you're running into some scenario, where you've got some
problem that's coming up within debug builds
in particular only, and you're trying to
replicate that bug, that's when you'd really want to
use the diagnostics tool window. >> Cool. That makes sense.
With all of these tools, I'm sure there's got
to be some drawbacks, or just some issues that users might experience when trying
to profile their code. Are there any current
existing workarounds, or ways to optimize this experience
to be the best that it can be? >> Absolutely. Yeah, I want to
go a few optimizations here. By the way, all the docs will be in the description below for this video. We've got a doc actually dedicated in literally just this concept about
optimizing profiling settings, and I want to touch on a few
high-level points and a few tips. Let me go back to VS for a
second here, and stop debugging, and walk you through some
of the different tips and things you might want to
consider when profiling to optimize the
performance of our tools. The first thing I want to do is
go to the performance profiler. Again, in this case, this
is going to go all to F2, and we've gotten this up. Let me just go ahead and say that, we do the best we can to
provide the smartest defaults possible for our customers to
really help them get going. I say that to say that the defaults may be good
for you in many situations. Tweak these and be cautious when you tweak these because you may
not necessarily need to. Only do this if you have to,
but these are just some ideas. If our tools aren't
acting the way you want, or if performance is
a real issue that you can have some of this more
configurability if you'd like. I'm in all to F2, and
for a few of our tools, like the CPU usage, the .NET object allocate as well, we allow you to adjust sampling
rates. How do you do that? I'm on the summary page, and then I click on this "Gear Icon". I'll just show with
the CPU usage tool. If I click this, I get
this properties page, and essentially this is
adjusting the sampling rate. Essentially, how much data
am I capturing per second? Like I said, we try to do the best we can with reasonable defaults. I personally haven't had
to mess with this much. Of course, I'm not doing as complex investigations
as our customers, but if you do need to change
the sampling rate, it is here. This is one area I might start with. We have low, we have high, we also have a custom option. For now, I'm just going
to leave it on default, but again, just wanted
to call that out. Changing the sampling frequency
might be a place to start. >> Can you change the sampling rate via the diagnostic tools window? >> Yeah. It brings you back to the exact same profiler
properties page, and you can do that as well. >> Sweet. >> We talked about adjusting
a sampling rate there. The next thing I want
to talk about is just keeping your
trace duration short. There's not a whole lot
to show here, but I'll just run through a very
quick demonstration. When I check the tool,
the CPU usage tool, I can start the collection
in the profiler. But the key thing to
note here is that, when this is collecting, and my app is going to load
up in a second here. But this is collecting a ton of data, and it just went
ahead and stopped it. But basically, I would recommend you keep your trace
duration under five minutes. We try to recommend that
to customers because it's pulling in so much data, that if you keep that trace
going for a long time, it's going to take forever
to bring up those results. That was literally a second to
obviously load it very quickly, it doesn't need to be
that short, of course. But my point is, just try to keep
the trace duration a bit short. Then the next thing I want
to talk about is the concept of just my code internally. But basically it's
really at a high level, it's the concept of user
code versus external code. Basically, many tools within the profiler have this concept of
user code verse external code. Essentially, user code
is anything that's built locally or rather
built by an open project, or open workspace that you have up, and external code is everything else. Why is this important? At
the end of the day, Leslie, something we've been talking about is we to create actionable
insights for customers. Things that they can actually
impact and have control over. Examples of external code might be a third party dependencies
or libraries, things that you're importing in, and you don't have as
much fine control over. If there's a performance issue
with something third-party, maybe that's important to call out, but at the end of the day, you don't have control over
optimizing that so much. With showing, or not showing external code
or showing just my code, what that allows us to do is
collapse all that external code, and I'll show this here in a second, into a single external code frame. What that allows us
to do is essentially drastically reduce the amount of
data processing that's needed, and it just makes our
tools work a lot better. How would I actually enable that setting? There's a
few different ways. Again, we're going to link the
docs which shows you as well. But in the case of
the CPU usage tool, you'll see this show
external code box here. There's a checkbox,
I had it unchecked. Because our external
code is unchecked, when I come over to my functions, everything is nicely collapsed
into this one frame. Had that not been unchecked, it would be a lot more, and it would have taken a
lot longer for this to load. For other tools like the .NET
object allocation tools, we have a button that
literally says show just my code that does
the same thing as unchecking the external code box. But I just wanted to call that out. Then the last setting that I'll talk about is optimizing
profiling settings. I've been plugging the docs a lot. Why don't I just go ahead
and show the docs real quick just for this one little bit. This is going to be one of
the docs that we link here. This is literally the optimizing
profiling settings doc. It talks about at a high level the different
points we already covered. But I want to focus on this last bit, which is the symbol setting section. This you can access right
within Visual Studio, which is debug option symbols. If you go through that
pathway in the context menu, you'll get to this page. Essentially, symbols can give
you information that can help you with investigating exception
issues or allocation issues, but they have a significant impact on how long it takes to
generate results for the tools. What's happening in
this particular menu, is that we have symbol
file PDB locations. PDB files are essentially where the symbols are stored,
and essentially, the symbols are very
expensive to load, so what we try to do is cache
them as much as possible, so you're not having to
constantly reload them. However, over time, sometimes
symbols can really slow things down. If you're struggling to load this, essentially what you
need to do is make sure that you might want to consider turning off like some
of these symbol server. In this particular picture, these symbol servers are off, but you might want to also
empty the symbol cache. For the profiler, or the way
it's designed right now, regardless of your symbol
loading preference here, it always has to load all symbols, which can be pretty taxing. But sometimes you want to
just rely on local symbols, and not have to load all this stuff. Again, maybe this is not the first place to look
for optimizing settings, but something to consider. Check out our documentation,
plugging it here again. But that's the last one. >> We technically talked
about two different tools, one being the performance
profiler and the other being the diagnostics tools window, but each of those windows had many tools within
those larger windows. What is the biggest takeaway
you want viewers to get from this very broad tour of those two major tools
that we're going to dive into in later parts? >> To your point, that they feel we have a pretty
comprehensive tool set. We have a lot of options for you, and hopefully you
feel that regardless of the nature of your
performance investigation, we have some tool for you somewhere within the diagnostics tool window
or the performance profiler. If you feel like we don't, we definitely love to hear your
feedback and work on that. We're constantly trying to make sure we have a very
comprehensive experience. Absolutely would love to
hear that feedback too. Also the fact that not just
we have a bunch of tools, but you can use them in tandem. We saw in the performance profiler, whether it's something like
checking multiple boxes, and running a few tools side-by-side. We saw with the diagnostics
tool window bridging the gap between the debugging
world and the profiling world. Using either just multiple of those tools together
with the CPU usage, and memory usage tool in that
window with time filtering, or just breakpoints go
into the CPU usage tool. Essentially, to recap, the
big takeaway is hopefully you feel we have a lot of tools
that work well for you, and that you can use them in tandem, and that you feel we have
adequate documentation, you can optimize the settings
to your need, of course. >> That's great. From there, when we get to our next part, just as a mini teaser, what
are we going to talk about? >> Absolutely. With this episode, it was all about tools and a little bit tipsy here and
there with settings. What we want to talk about
next though is how do you interact with these
tools outside of VS, and also taking this
to the next level. How do we profile in production? I think that's definitely a
question that comes up a lot, and it's very important
for obvious reasons. A lot of developers work in
production environments, and they want to figure out
how do we use our tools, not just within the
context of VS itself, but also outside as well. Our great colleague Esteban is going to be working
on that next episode, and so excited that. But we'll be getting to that next. >> Sounds fun. Thanks for
joining me once again, Sagar. >> Great to be here, Leslie.
Thanks for having me. >> Hopefully, everybody has been
enjoying this series so far, and is ready to take their
profiling to the next level. Join us next time for part three. Until then, happy coding. [MUSIC]
