>> Profiling in Visual Studio is getting a lot
more visual with the brand new flame graph.
Joining us is Misty Hays here to tell
us more on this episode of Visual Studio Toolbox.
>> [MUSIC].
>> Hey everyone, welcome to
another episode of Visual Studio Toolbox.
I'm your host, Leslie Richardson.
The topic for today is all about profiling.
Joining us today is
Misty Hays from the Visual Studio profiling team
who's going to share a bit more about what's new in
the world of profiling. Welcome Misty.
>> Hey, thanks.
Today I'm going to talk about the flame graph.
Our devs did a really good job on the team of making this feature.
Basically a flame graph,
in case people aren't aware,
is visualization of categorized data
created to help visualize stack traces of
profiled software so that
the most frequent code paths can be identified quickly.
The cool thing about it is it helps you
identify hot paths in your code.
It's one of the cool new things that we've been working
on for a while and we're actively working on this.
I would love to talk more and more about it.
>> Yeah. I love that
the profiling team uses flames and hot all the time,
when describing stuff I think it's great.
What are you referring to exactly when you
say like hot paths and flame and stuff?
Is that the primary area of focus that a developer
should be looking at when trying
to diagnose what's going on with their code?
>> Yeah. Basically if you're a developer and say you
have a web app and say that you're using an API or different APS.
You're calling, and you're making a request for the API and say,
for instance, you're getting a slow response time.
You're trying to figure out, why is my response taking so long?
What's going on? Some of
our profiling tools can help you figure out why it's so slow.
I know that's a common problem.
A lot of times, especially when you're
a new dev is like trying to figure out,
I'm starting to work with APS
and I want to make sure that my code is performant.
But a lot of times the tools,
it can be difficult to know where to start with them.
We usually recommend that people start with
the CPU usage tool to give you a general idea
on where the hot paths are in your code or
the parts in your code that are taking a little bit of time.
Flame is a good representation of that,
because that's something that we are familiar with,
even just from video games and lava from video games.
It helps you visualize a call tree a lot easier and
it gives you a visual overview of where time was spent.
Those are things that the flame graph does to
help you understand quickly,
where you should focus in your code to make it more performant.
>> Yeah. Makes sense except unlike lava,
I think actually want to jump into this one.
Shall we check out how this was works?
>> Yeah. Sounds good. The first thing
you want to do is you want to hit "Alt F2",
that's the keyboard shortcut.
Then you want to go and you want to select the CPU usage tool.
>> Awesome tool, by the way.
>> Yes. It's great.
Useful when the CPU is
the performance bottleneck and also a great starting point.
Then you want to click "Start".
While this is going on,
while we're collecting data basically,
right here at this point,
a lot of people ask questions like how long should I let it run?
You want to let it run at least 30 seconds to a minute.
If you have a pretty complicated system
or a web app that you have,
maybe a little longer,
but you definitely don't want to go longer than five minutes.
Usually within 30 seconds to a minute, you'll have enough data.
>> Well, what happens when they hit that five-minute of mark?
You run out of space or memory?
>> Yeah. There's a lot of things that can happen.
There have been instances where things didn't load properly.
Because you get a lot of data back and we're
giving you all of this information back in this session.
If you're already looking into performance,
you don't want to do anything that's going
to make your performance slow.
Just like even reviewing a report.
It's best just to stick with to air on the 30 seconds to a minute.
Then you can always run it again and do it
for longer if you need to.
>> Cool. Make it a quick coffee break, in other words.
>> Yeah, exactly.
>> Let's wait for some results.
>> Yeah. Then from here you want to go to open details.
Now the currently this is the only way to open
the flame graph is the way that I'm showing you.
We don't have another way to right now.
Then next thing you want to do is,
right here you see current view,
you want to switch this to flame graph.
It's cool. The app that I'm using
to walk through this is a smaller app.
It's an app that is a web app and it's a book inventory service.
It's a small app,
but already you can see things,
and already looks like icicles.
>> Yeah. It does look like icicles too.
>> No. It's like it starts to look familiar and then you're like,
icicles will always an icicle and not a flame.
I can talk about that.
By default it will show the icicle version like that view.
Because this is the view that a lot of people are familiar with.
You can just click "Flip Flame
Graph" and it'll flip it the other way.
>> That's pretty. Is it essentially the same data
just reversed, in this case?
>> Yeah. Some people like seeing the data this way,
and then some people like seeing it the other way.
It's just a preference
on what someone would want to look at first.
This is the part of
the flame graph that we're really
trying to work on right now is like,
how can we make this easier to understand?
We've gotten some feedback about the name space here,
and how if you have
a pretty big web app or
a pretty big app and the names are similar,
and it's like this that it's hard to read,
and that is something we are actively working on.
But there's also things like,
do these colors make sense?
Does color play a part in this?
Would that be easier?
What information would someone like to see?
Because currently if you right-click,
you see a little bit of information,
but you don't really see a lot.
We're trying to figure out what would help
devs to where they'd want to use this
and where it would really help
them when they're drilling down on something.
Especially if they want to drill down on a specific node.
I will do that one
>> Our option currently,
drill down into one of these nodes.
>> Like I said, this is a simple web app.
You have this node and then you have all the ones under it.
If someone's new to profiling or they're new to diagnostic tools,
or even just looking at performance.
In a web app, we want to make this simpler to understand.
Like I said right now,
what do people want to see there, if they click this?
We try to find a good one here where we can look and see.
Because if you find a lot of these are just three.Net,
alot of these nodes are.
But if you look at some they're, here we go.
It'll actually take you to the code.
>> Awesome. Could you go into
code that's not yours if you wanted to or if you are curious?
>> Not in here. Not really.
It just says that basically it's unavailable to look at.
I'm sure in some scenarios you might be able to,
but in this particular one,
it basically just doesn't do much.
Let's find the book service, and I'll show you.
Well basically what happens is when you click on
this and you drill down into this part of the code,
it'll actually take you up into your code.
It'll take you there and I'll show
you in your code where this is happening.
That way if you're looking at
this and it's overwhelming you're, well,
since this is a books inventory app,
basically I'm making a catalog
of all the books that I want in my house.
Just say you're doing that. It's like, well,
I know that I'm inputting a lot of data and I know that
that can be slow if I didn't implement that correctly in the code.
That could be my error.
I know that's going to be hots-pot anyway.
Let me just find that real quick and just drill in there.
That's how you would be able to click right here,
and then it would pop up in the code and then you
can make the changes and then see a difference.
>> Cool. It could give you the exact lines or lines where bad?
In this case, CPU usage just increased dramatically.
>> Yeah.
>> Awesome.
>> Cool. Does this flame grap apply to
other pieces of the performance profiler or will it someday?
>> Possibly. We're looking
into a lot of things right now on how to make
like where does it make sense to show
this data and where does it make sense to show the flame graph?
We have the tool in visual studio and the profiling tools
where the top insights,
if we notice something in your code where we're like,
Okay this might be a performance issue.
Like if you're on an older version of dot net,
it will pop up here to say, hey,
you'd be this Tom's more fast or faster
if you implemented or you like did this with your dot net.
We're also looking at ways like one thing we're
thinking about now is like how does
it make sense with the flame graph?
Like depending on what, what help Devs,
what information that we
use in the flame graph like that they would want.
We're also thinking about how that relates to
top insights because we've gotten a lot of
feedback from devs that one thing
that would help them would be more information on
non-performant like data structures or algorithms like they
want to know those things and they
want that called out in the top insights.
We're thinking about that and does it make sense in
the flame graph like where should we put that information?
There may be some crossover between that and
top insights because we're also working on that right now too.
But we're pretty open on what would
make sense right now and we're taking feedback for it.
If anyone has any suggestions,
definitely let us know.
>> I was going to say, I'm assuming this means that
you want people's feedback and they should definitely go
to the developer community or thing you want
on Twitter about things that can be brewed? Awesome.
>> Definitely, Yeah. Even if it's like
a color thing or something,
that makes more sense for accessibility.
Because this is something that we're working heavily with
on the accessibility team is making sure it's accessible.
If anyone has any suggestions
on that or they would prefer
certain things because it would help accessibility,
I would love to hear that too.
Because obviously we want to make it to
where everybody could use it and I'm open to feedback.
If you want bloom purple we'll look into it.
If you want icicle and flame, you want red,
we'll look into it, make sure it's okay for everyone.
>> Cool. Does it change with the theme?
Because then as you have your own VS theme
going so I'm wondering if
the changes their tweets itself based off of.
>> No I don't think so. I think the theme that I'm using is dark,
but it's an accessible theme.
>> Okay, cool.
>> Yeah. I know everyone always says that.
[LAUGHTER It's like it changes the letters a little bit so
they're easier to read because I'm dyslexic,
so I want to make sure that I can have
enough space in between the letters saw don't
glance especially if you're looking
at that code and you want to make sure that
you're not wasting your time
looking into a part of your code that sounds like something else.
>> Yeah. It makes sense.
>> Yeah.
>> Sweet. Well, I like having more visual ways
to represent ways where your code can be improved.
I know profiling can be a hustle sometimes where it's like, well,
it worked when you ran it locally and
then [LAUGHTER] the moment it went out
into the wild, all of a sudden it's like,
>> Yeah.
>> Taken a dip in performance or wherever else is going on
so using that is a little bit helpful.
>> Yeah, there are also a lot of things can
happen like why you're profiling.
One thing that we're working on that's related to this
is a doc where we're going to outline
possible errors that someone could
have while they're profiling and tell you how to
get unblocked from that because
sometimes there's little things that you could click,
like this button here,
like this right here.
If you don't click, "Release" here and you leave this on debug,
you get a different experience.
Now you know all about that.
But this is like a common thing
that the people don't select "Release."
>> Yeah, that's a very good one.
>> Then it's a mess. It just
depends on what you're doing, but definitely yeah.
Visual is way great as long as it's great for everybody, right?
>> Yeah.
>> You definitely want the feedback.
>> Awesome. I totally support having a doc with
like common mistakes and stuff that
people may experience that would really help release
some frustrations that people have trying to figure
out what it's even wrong in the first place cell.
On that note also, where can people go to
learn about the flame graph today?
>> Yes. We are finishing up that doc right now.
We've added information in there about how to
use navigation with a mouse and with your keyboard.
It will be published any day now,
we're finishing in the BR now but if anybody has any questions,
they can totally tweet me.
The good thing about our Devs is
that we have surveys and we do read every response
so I do appreciate the people who
ran into an issue with profiling and they
actually copy and paste
the error message that really helps us out.
We do read that and that was the inspiration for the doc.
Would you real those.
>> Awesome.
>> Thanks to people that took the time to do that.
>> Yeah, send your feedback people.
There are real people reading your feedback,
we're not just robots. [LAUGHTER]
>> I read the verbatims, I read all of them.
>> Yeah.
>> Yes.
>> Awesome and definitely reach
out some Misty on Twitter. She's awesome.
She also post really cool retro staff
when it comes to tech as well.
You should definitely follow her.
[NOISE].
Without anything else, Misty?
>> No, I don't think so. Is anybody wants to chat?
Just let me know and I want to definitely hear the feedback
and hear how we can make it more
accessible and just like better for everyone.
But no, I think I'm good.
We have a bunch of stuff coming
so keep looking for that because it's some good stuff coming.
>> Awesome. Also if you want to learn more
about the performance profiler in general within Visual Studio,
we did a whole series on it way back when with shouts to
Stagger and S Divine
and we'll probably link that in the show notes.
Definitely check that whole series
out if you want to learn even more about
how that thing can change your life
when it comes to profiling your programs.
Thank you Misty for being here and I'm sure we'll see around on
the show because there's always something cool happening in
profiling land and I think that people need to know.
>> Yeah, sounds good.
Thank you for asking me and
it was great and I hope to hear from people soon.
>> All right, so till next time, happy coding.
[MUSIC]