>> You finished writing your code,
you've debugged it, it works great,
you pushed it out live and now
you're experiencing performance issues.
You want to know how to fix those issues,
in this multi-part series of Visual Studio Toolbox,
we're going to be talking all about profiling in Visual Studio.
[MUSIC]
>> Hey, everybody.
Welcome to Visual Studio Toolbox.
I'm your host Leslie Richardson.
Today, I'm joined by my colleague,
[inaudible] , who is a PM on
the profiling team, welcome [inaudible].
>> Thanks for having me, Leslie. I'm glad to be here.
>> Awesome. For those of you who don't know,
I'm actually a member of the Visual Studio debugging team which is
a smaller team in the larger Visual Studio diagnostics world,
and that's where the profiling team comes in.
In this multi-part series,
we're going to be talking all about profiling,
but what exactly are we going to be
talking about profiling, [inaudible]?
>> Yeah. So just to give an overview of the series,
I'm really excited for this.
Basically, what I thought we'd do is start with
a high-level overview of profiling in the first few episodes,
and really by the end of the series,
do a deep dive on
all the various tools of the Visual Studio profile offers.
>> Great. To me,
and I think a lot of other people,
profiling is that thing you do after
you're done debugging things and you go ahead and ship your code,
people start complaining to you about how your app is too slow,
and then you have to quickly learn up on
all those tools that maybe you didn't think twice
about in Visual Studio in order to
determine how to better improve your performance,
but can you tell us a bit more about what profiling exactly is?
>> Yeah, definitely. Like you say Leslie,
it really is the next level of diagnostics past debugging.
So there's definitely as we say internally,
the inner loop scenario of day-to-day,
trying to make sure that your code first of all just
compiles and just has a similar behavior to what you'd expect,
but really there's that next level of
diagnostics pasts that which is, "Okay,
maybe my application does compile it,
but I want it to be a little bit more efficient,
a little bit more performant, I want it to be a little bit faster.
So that's really where profiling comes into play.
To be fair, not necessarily
every Developer focuses on this diagnostics,
but there is a certain subset that does
and we cater to those Developers and make sure
that they have proper and adequate tools in
place in order to be able to solve those challenges.
This is done by essentially measuring
the performance of the applications data as it run,
capturing that performance data and
then going back and looking at it,
and we'll talk more later about how our tools go about doing this.
Really when we're talking about performance,
it's not necessarily just one metric we're looking at.
I mean, performance can refer to a lot of things,
but at a high level it could refer to wall clock time,
just the amount of time that the application is taking
to run or complete certain operations,
CPU time or CPU cycle,
the amount of time you're holding up like
a CPU or it's taking to process certain tasks,
and also memory usage as well in terms of
how much memory you're allocating
for different objects and things like that.
There are a lot of different metrics we look at,
and we have a lot of different tools to support
those different performance investigations.
>> Cool. So when you start
profiling or if you're just curious at all about it,
why else beyond just the basic,
it improves your performance should you care about profiling?
>> Yeah. So I think there's quite a lot of value in what
profiling offers on both to
the costumer and on the business side as well.
So just trying give some examples.
On the customer side and the user experience side,
I think everyone just likes performance,
better performing applications, faster performing applications.
>> Who doesn't?
>> I'm sure you've been there Leslie,
where you take a mobile app or web app or any app,
you just load it up and it's just sitting there and
it's hanging and it's not loading, it's taking forever.
There's certainly a lot of value to the customer
in terms of making sure that the application,
even if it does work eventually, it's not good enough.
It actually needs to work in a certain time period.
Less waiting, I think it
leads to just happier customers in general.
On the UX side, there's definitely some value there.
On the business side, there's also I think cost to consider too.
I think if you're hosting an application in the Cloud,
and you're having to pay for VMs and stuff like that,
if you have certain optimizations and you
design your application in such a way that maybe is
a little bit more performant from a CPU
standpoint or takes up less memory
perhaps you don't need as many VMs to support your applications,
and as a result your costs are lower.
There's definitely a lot of value there on the business side.
Lastly, we're living in a world now where we're having
to design software for various constraint scenario.
We support IoT profiling and there are customers that
we've worked with and done profiling extensively such
as the HoloLens team at Xbox team,
and they have products that are operating in
very specific and interesting environments such as VR,
and also just gaming engines that need to be performant,
because their customers are
expecting a certain amount of performance,
and if they're not performing,
those applications aren't necessarily as desirable to use.
Thinking about some of those constraint scenarios,
profiling is definitely at the forefront
of a lot of different people's minds. Yeah.
>> Awesome. Particularly, the cost point stood out to me the most,
who doesn't like things to be cheaper especially when it comes to
developing large-scale applications and things like that?
>> Yeah, absolutely.
>> Awesome. As a PM on the profiling team,
what kinds of customers do you typically
see using the profiling tools that you create,
or what kind of customer base
would you like to see using it more frequently?
>> Yeah, absolutely. At a high level,
it's going back to performance,
so the general motivation is anyone who wants to
make their application faster or more
performant is the impetus or
the initial reason why you come to our tools.
I will just say that if you
haven't used our profiling tools before,
definitely, I would recommend checking.
Now there's a chance that you might get
some pretty easy quick wins and really make
your application a bit more performant, but more than that,
it's generally people that are investigating issues that don't
necessarily break your program
in terms of preventing it from compiled,
but it's just too slow or maybe you're mismanaging memory and
you're out of memory to allocate for other things.
To be a little bit more specific
than that in terms of talking about
something like the industries and markets we operate in,
alluded to it before but like game Developers are
really big into profiling because
performance is so key to their product.
Another internal customer we worked close with
is a company that builds a 3D rendering software,
and that acts like a very graphically intensive tool.
So they heavily use our products because
performance is key to them as well.
>> Great. I know for
me anytime I see a memory-related issue when I code,
it's the worst thing you can possibly get because I mean,
where do you even start.
>> Yeah.
>> Yeah. It seems that goes under
the larger just general performance issue umbrella.
When talking about performance,
what are some other things that can count as performance issues,
because we always talk about performance like it's
just this one singular thing when it's actually pretty big.
>> Yeah. That's a great point. I would say that generally speaking,
there's a lot of different, to your point,
performance issues that can come up.
But generally speaking, they fall into a few different buckets,
so I'll go over some of the common buckets that pop up a lot.
For one, I would say mishandling CPU time.
This comes back to just
using bad or maybe slightly not modern practices in code.
One thing I know you're very familiar with Leslie
is asynchronous code and using that pattern.
>> Yeah.
>> Yeah. Definitely, if
you're not necessarily using asynchronous patterns or
patterns where using nested loops and having to
constantly iterate multiple times over large datasets,
that's going to slow down
your CPU and really make your application less performant.
Furthermore, things like not caching properly,
so maybe you're making an API call to
some external dataframe or
dataset and loading it up like a large dataset.
If you don't cache that
properly and every time you make that API call,
you need reload that large dataset,
that's also going to slow your application down.
Another thing under CPU time is string building and logging codes.
This is a bit of a debugging diagnostics thing,
but as you're building out those strings,
that operation is really expensive and that
cost is distributed across your whole application,
so that can really slow down the entire application.
All of those bad patterns,
not using asynchronous code,
not caching properly are examples of
different patterns that may show up under mishandling CPU time.
To your point about mishandling
memory and that being tough to solve,
that's definitely another high-level issue we see a lot.
That comes down to maybe allocating too much memory or
too often or not deallocating memory.
Once you've had your field with
the specific object and hanging on
to objects will pass their lifetime,
this leads to not garbage collecting properly.
Luckily, if you're operating within
some managed memory languages
like C#, for example and using the.Net Framework,
the runtime does take care of some garbage collection for you.
It's definitely getting better at the runtime level with that.
But we do have tools that help you
visualize issues with your memory allocation which is tough to do,
otherwise, without the tools.
Also, we have tools that can help force garbage collection,
because even though the runtime does
a decent job of collecting on its own,
sometimes, and we'll talk about these scenarios in
future videos where you may want to force that garbage collection,
we have tools that are able to help you do that.
So we talked about mishandling CPU time,
we talked about mishandling memory,
the last major bucket I'll talk about
is external dependencies of your app.
Obviously, you have your user code,
but if you're making API calls over
different networks or slow database
calls where you have these external dependencies,
it's a bit tricky to figure out
maybe what's going wrong because you don't necessarily
have access to all of those
external different bits you're playing around with.
So we have tools for that as
well that can help you deal with those scenarios.
>> All right, cool. So at this point,
you've figured out that
you're having performance issues in your code,
it could be a memory issue,
or a CPU issue,
or external dependencies that are
just too slow to respond, now what?
For most people who don't know these tools chances
are they probably got to play the trial and error game with this.
So how can we be taking more advantage of
the existing tools in Visual Studio to fix these issues?
>> Definitely. So we talk a little bit about what
profiling is and the common scenarios like you suggested.
Now, I wanted to end this video with a little teaser,
what's the common time of getting started?
I'm going to launch Visual Studio and share my screen real quick.
Now, we're in Visual Studio, and basically,
I want to answer the question,
how do I get started and start using
some of the Visual Studio profiling tools?
Just to mark this up,
I have an ASP.NET Core web application loaded up.
To get started with some of the profiling tools,
what I'll first introduce is the Performance profiler.
What is it and how do I get there?
To get to the Performance profiler,
there's a few different ways,
but you can go to Debug and
then click on the "Performance Profiler" in the Context menu,
there's also this keyboard shortcut,
Alt F2, also click on this button here.
Now we get to this particular summary page.
We'll go in to the Performance profiler more in-depth
in future videos, but basically,
it's a suite of tools that allows you to drive
your performance investigations and
look at a lot of different of kinds of metrics.
We have the CPU Usage tool to do different CPU investigations.
We have a few different memory tools,
you've got a new Async tool to see where
your application is spending a lot of time with certain tasks.
Today, I'll just showcase
the CPU Usage tool and highlight
just the basic collection process,
because this is one of our most used tools.
We'll talk about this more in a future video,
but you can use a few of these tools in conjunction.
There's also a bunch with in terms of
optimizing different profiling settings.
But for now, I'll just keep the defaults on.
>> This interesting. It's like
the profiler has its own little world.
>> Yeah.
>> Menu screen and everything.
>> Yeah. It's got a lot of different tools and it's
creating this diag session as you can see here.
One cool thing about this is
once you're done and you collect a bunch of data,
you can send it to a colleague and they
can load it up on their machine and
help you with that investigation by
seeing what happened on your machine too,
so you have a little bit at collaboration there.
Once you have the CPU Usage tool clicked,
you can hit "Start" to start the process.
In the interest of time now,
I've already done the collection,
but you'll hit "Start" and let it run for a few seconds,
and then there's a Stop Collection button.
But at the end, what you'll get is an output of this report.
So this is our CPU Usage tool,
and again, we'll have a whole dedicated video to this.
But basically, with most of our tools,
they have this swimlane up top,
which has a graph to
show some basic data points over time generally,
and then we have some tabular view
and it really depends on the tool,
like what that table is showing.
But basically here, we have
some functions that are of interest and are taking up
a lot of the CPU and some hot paths which are
essentially some areas of code
that you should really go back and dig into that.
Also, in this case,
taking up a lot of the CPU's resources.
>> There's nothing more astute looking
than having graphs in your presentation.
>> Yeah. You got to love the pie chart.
>> When I have to make presentations sometimes,
I always get really excited when I'm able to include a graph,
it's like, "Oh man, much more official now."
>> Yeah, for sure. So yeah,
that's basically a summary of the Performance profiler, again,
we'll totally go into a more
in-depth overview of this in the future.
But for the enthusiastic learners amongst us,
if you really want to dig and get started,
go to the Performance profiler,
go to Alt F2, and then play around with the tools.
>> That's great. From my experience,
I am familiar in the Diagnostics Hub window,
it also has a CPU Usage tool.
What's the difference between the two?
>> Yeah. In our next episode,
we're going to unpack that a lot more.
But basically, one of the advantages with that window is it
allows you to take advantage of all of
our great debugger features that you are well aware of, Leslie.
>> Yeah.
>> Having worked on that.
>> Of course.
>> So it's really cool to get that interaction between some
of the profiling tools that we have as well as the debugger.
So the Diagnostics Tool window is
really using those two in conjunction.
The Performance profiler is more like the stand-alone tools,
a little bit more robust,
and you also get a few different visualizations,
because we just have some tools in
the Performance profiler that don't necessarily
have an equivalent counterpart in the Diagnostics Tool window.
We'll talk about some of those more unused
tools later on, but yeah.
>> So on a larger scale,
before we do deep dives on
each different really awesome feature and the later parts,
what would you say are some of
the hardest challenges when it comes
to developing for the profiling space?
>> Wow, that's a really good question.
I would say at high level,
there's two main challenges.
One is that we collect tons and tons of data.
So something we really want to
do for our customers is make sure that
that data is very digestible and easy to visualize and actionable.
So figuring out how we want to best visualize
the large amounts of datasets that
we deal with is I think a bit tricky.
Second thing, along those lines it's
tying that data back to the code,
and essentially figuring out how can you connect,
because we have tons of data that are spit out,
and again, we want to make sure it's actionable.
So being able to highlight
the specific parts of
your code that are of interest and of
the areas that you need to focus on.
To fix your problem is ultimately another big challenge.
>> That makes total sense.
I can only imagine having to try to sift through a giant list of
information and being unable to quickly
locate the actual hot point.
>> Yeah. That's so a lot of [inaudible]
>> Great.
Do you have any final thoughts before we dive
into all these really cool tools and later parts?
>> Yeah, again, just really excited to start this series.
In the next episode,
we're going to go over
the Performance profiler a little bit more in-depth,
talk about more of the tools, because again,
we've just briefly talked about the CPU Usage tools today.
We'll also be doing a little bit of
an overview on optimizing settings,
going over scenarios where you can start to
use a few of the tools in tandem.
Then also, hopefully, mentioning
the Diagnostic Tool window that you brought up,
Leslie, the one that it's more integrated with the debugger.
Again, going back to the idea of how can we best use the few of
these tools in conjunction and not just focusing
just on one tool. So yeah.
>> Fantastic. Well, thanks for joining me [inaudible] .
I look forward to having you join us for future episodes to come.
>> Thanks for having me. I had a good time.
>> Great. See you-all later.
[MUSIC]