 So you finished writing your code, you've debugged it, works great, you've pushed it out live, and now you're experiencing performance issues. You want to know how to fix those issues, and this multi-part series of Visual Studio Toolbox, we're going to be talking all about Profiling in Visual Studio. Hey, everybody. Welcome to Visual Studio Toolbox. I'm your host, Leslie Richardson, and today I am joined by my colleague, Sagar Shetty, who is a PM on the Profiling team. Welcome, Sagar. Thanks for having me, Leslie. Glad to be here. Awesome. So for those of you who don't know, I am 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. So 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, Sagar? 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 that the Visual Studio Profiler offers. Great. So to me, and I think a lot of other people, Profiling is that thing you do where 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. So it's a lot like what you say, Leslie. It really is the next level of diagnostics past debugging. So there's definitely, as we say internally, the interloop 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, right? But really, there's that next level of diagnostics past that, which is, okay, maybe my application does compile, 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, right? So that's really where Profiling comes into play. To be fair, not necessarily every developer focuses on this kind of 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 kind of challenges. This is done by essentially measuring the performance of the application's data as it's 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. And 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 kind of wall clock time, just the amount of time the application is taking to kind of run or complete certain operations, CPU times 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. So there are a lot of different metrics we look at, and we have a lot of different tools to support those different kind of performance investigations. Cool. So when you start Profiling, or if you're just curious at all about it, why else beyond just, yeah, like 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 customer and kind of on the business side as well. So just kind of give some examples. So on the customer side and the user experience side, I think everyone just likes performance, like better performing applications, right, faster performing applications. I'm sure you've been there, Leslie, where you take a mobile app or web app or any sort of app that you just load it up and it's just sitting there and it's hanging and it's not loading the same forever, right? So there's certainly a lot of value to the customer in terms of making sure that the application, like even if it does work eventually, it's not good enough. It actually needs to like work in a certain time period. So less waiting, I think it needs to just happy your customers in general. So on the UX side, there's definitely some value there. On the business side, there's also, I think, cost to consider too. So 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. So there's definitely a lot of value there on the business side. And lastly, we're kind of living in a world now where you're having to design software for various constraint scenarios. So devices, we support IoT profiling and there are customers that we've worked with and done profiling extensively such as like the HoloLens team and Xbox team and they have products that are operating in very kind of specific and interesting environments such as VR and also just kind of like gaming engines that need to be performant because their customers are expecting a certain amount of performance and if they're not performant, those applications aren't necessarily as desirable to use, right? So kind of thinking about some of those constrained scenarios, profiling is definitely at the forefront of a lot of different people's minds, yeah. Awesome. Particularly the cost point came out, stood out to me the most, like who doesn't like things to be cheaper, especially when it comes to developing large scale applications and things like that, right? Yeah, absolutely. Awesome, so as a PM on the profiling team, what kinds of customers do you typically see using the profiling tools that you create and or what kind of customer base would you like to see using it more frequently? Yeah, absolutely. So at a high level, right? It's kind of going back to performance. So the general motivation is anyone who wants to make their application faster or more performant is kind of the impetus or like the initial reason why you kind of come to our tools. And I will just say that like, if you haven't used our profiling tools before, definitely would recommend checking that. There's a chance that you might get some pretty easy quick wins and really make your application a little bit more performant. But more than that, you know, it's generally people that are investigating issues that don't necessarily break your program in terms of preventing it from compile, but it's just too slow or maybe you're mismanaging memory and you're out of kind of memory to allocate for other things. To be a little bit more specific than that in terms of talking about some like the industries and markets we operate in, kind of alluded to it before, but like game developers are really big into profiling because performance is so key to their product. Another kind of internal customer we work close with is a company that builds a 3D rendering software. And that's like a very graphically intensive tool. So they kind of 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 like the worst thing you can possibly get because I mean, where do you even start? But yeah, and it seems like that goes under the larger just general performance issue umbrella. So when talking about performance, what are some other things that can count as performance issues? Cause 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. And I would say that generally speaking, there's a lot of different tier point performance issues that can come up, but generally speaking, they kind of fall into a few different buckets. So I'll kind of go over some of the common buckets that pop up a lot. So for one, I would say kind of mishandling CPU time. So this kind of comes back to just using bad or maybe slightly not modern practices in code. So one thing I know you're very familiar with Leslie is like asynchronous code, right? And using that pattern. Yeah. So definitely, you know, if you're not necessarily using asynchronous patterns or patterns where you're 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 sort of external data frame or dataset and loading up like a large dataset. And if you don't cache that properly and every time you make that API call, you need to reload that large dataset. That's also going to slow your application down. Another thing kind of under CPU time is kind of string building and logging code. So this is kind of like a bit of a debugging diagnostics thing, but as you're kind of 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. So all of those kind of bad patterns, not using asynchronous code, not caching properly are kind of 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. So that kind of comes down to maybe allocating too much memory or too often or not deallocating memory once you've kind of like had your fill with a specific object and hanging onto objects well past their lifetime. This kind of leads to not garbage collecting properly. And luckily, if you're operating within some managed memory languages like C-Sharp for example, and using the .NET framework, there is like the runtime does kind of take care of some garbage collection for you. So it's definitely getting better at the runtime level with that. But we do have tools that help you visualize kind of issues with your memory allocation, which is tough to do otherwise without the tools. And also we have tools that can help force garbage collection because even though the runtime does a decent job of kind of collecting on its own sometimes, and we'll talk about these scenarios in future videos where you may wanna force that garbage collection, we have tools that are able to help you do that. And so kind of, so we talked about mishandling CPU time, we talked about mishandling memory. The last kind of major bucket I'll talk about is kind of external dependencies of your app. So obviously you have your user code, but if you're kind of making API calls over different networks or slow database calls you have those external dependencies, right? It's a bit tricky to kind of 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 kind of 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, a CPU issue or external dependencies that are just too slow to respond. Now what? Like for most people who don't know these tools, chances are they probably got to play the trial and error game with this, right? So how can we be taking more advantage of the existing tools in Visual Studio to fix those issues? Definitely. So we talked a little bit about what profiling is and kind of the common scenarios like you suggested. And so now kind of wanted to end this video kind of with a little teaser into what's to come and kind of getting started. So I'm gonna launch Visual Studio and share my screen real quick. Okay, so now we're in Visual Studio and basically I wanna kind of answer the question how do I get started and start using some of the Visual Studio profiling tools? So to kind of to mock this up, I have an ASP.NET Core web application loaded up and to kind of get started with some of the profiling tools, what I'll first introduce is the performance profiler. So what is it and how do I get there? So 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. I'll just click on this button here. And now we get to this particular summary page. So essentially at a high level and we'll go into 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 kinds of metrics. So we have like the CPU usage tool to do different CPU investigations. We have a few different memory tools. You've got a new async tool to kind of see where your application is spending a lot of time with certain tasks. And today I'll kind of just kind of 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 the terms of optimizing different profiling settings. But for now, I'll just kind of keep the defaults on. This is interesting. It's like the profiler has its own little world. Yeah, yeah. Menu screen and everything. Yeah, it's got a lot of different tools and it's creating this DIAC session, as you can see here. And one cool thing about this is like, once you're done and you collect a bunch of data, you can send it to a colleague and they can kind of load it up on their machine and kind of help you with that investigation by kind of seeing what happened on your machine too. So you kind of have a little bit of that collaboration there. So once you kind of have the CPU usage tool clicked, you can hit start to kind of start the process. In the interest of time, now I've kind of already done the collection, but you'll hit start and kind of let it run for a few seconds. And then there's a stop collection button. But at the end, what you'll get is kind of an output of this kind of a 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, we kind of have this Swimlane up top, which has kind of a graph to show some basic data points over time generally. And then we have some sort of 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 kind of 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 are also in this case, taking up a lot of the CPU's resources. You know, there's nothing more astute looking than having graphs in your presentation. Yeah, and you gotta love the pie chart, right? Right? Like 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. And so yeah, that's kind of 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 anyone that's, for the enthusiastic learners amongst us, if you really wanna kind of dig in, get started, kind of go to the performance profiler, go to Alt-F2, and then kind of play around with the tools. That's great. So from my experience, I am familiar with in the diagnostics hub window, it also has a CPU usage tool. What's the difference between the two? Yeah, so in our very next episode, we're gonna kind of unpack that a lot more, but basically with that one, one of the advantages with that window is it allows you to take advantage of all of our great debugger features that you're well aware of, Leslie. Yeah. And so it's really cool to kind of get that interaction between some of the profiling tools that we have as well as the debugger. So the diagnostics tool window is really kind of using those two in conjunction. The performance profiler is more kind of like the standalone 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. And we'll talk about some of those more niche tools later on, but yeah. So on the larger scale, before we do deep dives on each different really awesome feature in the later parts, what would you say are like some of the hardest challenges when it comes to developing for the profiling space? Oh, wow, that's a really good question. So I would say kind of high level, there's two main challenges. So one is that we collect tons and tons of data. And so something we really wanna do for our customers is make sure that that data is very digestible and easy to visualize and actionable. So kind of figuring out how we wanna best visualize the large amounts of data sets that we deal with is I think a bit tricky. And then the second thing kind of along those lines is tying that data back to the code and essentially figuring out like how can you connect? Like cause we have tons of data that spit out and again, we wanna make sure it's actionable. So kind of being able to highlight the specific parts of your code that are of interest and 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 a lot of data. Yeah, great. So that, 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 the series. In the next episode, we're gonna go over the performance profile a little bit more in depth, kind of talk about more of the tools, cause again, we just kind of briefly talked about the CPU usage tool today. We'll also be doing a little bit of an overview on kind of optimizing settings, kind of going over scenarios where you can start to use a few of the tools in tandem. And then also hopefully mentioning the diagnostic tool window that you brought up, Leslie, the one that it's more integrated with the debugger. So again, kind of going back to the idea of like, how can we best use a few of these tools in conjunction and not just focusing, just kind of on one tool. So yeah. Fantastic. Well, thanks for joining me, Sagar. And I look forward to having you join us for future episodes to come. Thanks for having me, had a good time. Great. See you all later.