{"id":4751,"date":"2016-02-15T10:00:00","date_gmt":"2016-02-15T18:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/?p=4751"},"modified":"2019-02-14T15:30:15","modified_gmt":"2019-02-14T23:30:15","slug":"analyze-cpu-memory-while-debugging","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/analyze-cpu-memory-while-debugging\/","title":{"rendered":"Analyze CPU and Memory while Debugging"},"content":{"rendered":"

Would you like to learn how to make your code run faster, use less memory, or just find out whether your code has a CPU or memory issue? Of course you would\u2014you\u2019re a developer! But then, memory and performance tuning often suffers from the pitfall of being an \u201cimportant but not urgent\u201d task that you simply can\u2019t seem to get to because of the really urgent stuff. So why not bring that task little closer to you?<\/p>\n

In this post we\u2019ll look at how using the debugger-integrated performance and memory tools in Visual Studio 2015 Update 1. Without leaving your debugging workflow, these tools let you quickly answer questions like \u201chow is my memory footprint?\u201d \u201cwhat is using all this memory?\u201d, \u201cshould I be concerned about the performance of this code?\u201d, and \u201cwhy is this so slow?\u201d. Although we show ASP.NET in this post, these tools also work when debugging Windows desktop applications and C#\/VB\/C++ universal Windows applications that target desktop.<\/p>\n

If you like what you see in this blog post, please join our Visual Studio Performance Tools Community<\/a> to stay up-to-date and help steer future features.<\/p>\n

Finding Performance and Memory Problems<\/h2>\n

The first step in optimizing the performance of your code is to know where to make improvements. To help with this, PerfTips and the Diagnostics Tools window in the Visual Studio 2015 debugger give you inline, glance-able performance information.<\/p>\n

To use PerfTips, just set a breakpoint and step over a line of code, and you\u2019ll see the PerfTip appear to the right of the instruction pointer (the yellow arrow) with the elapsed (wall-clock) time. In this case it tells us that line 57 took 1406ms to run, which is usually a combination of time spent waiting on I\/O (e.g. an HTTP call or reading a file from disk) and time spent executing code on the CPU:<\/p>\n

\"PerfTips\"<\/a><\/p>\n

If this number is higher than you\u2019d like, run the same code a few more times to see if you get consistent results. In many cases, you can Click+Drag the instruction pointer (yellow arrow) back to re-run code without having to stop your debug session<\/a>.<\/p>\n

To look at your app\u2019s CPU and memory consumption, open the Diagnostic Tools window<\/a> (Debug > Show Diagnostic Tools<\/b> or Ctrl+Alt+F2<\/b>):<\/p>\n

\"Diagnostics<\/a><\/p>\n

The Diagnostic Tools window opens by default when you start debugging, and you can leave it open to keep an eye on your app\u2019s CPU and memory consumption whenever you are debugging.<\/p>\n

Hover over the CPU and memory graphs and you\u2019ll see a tooltip that shows the application\u2019s private memory and percentage of CPU consumption at any point in time:<\/p>\n

\"Tooltips<\/a><\/p>\n

Above the memory graph you\u2019ll see a timeline of the breakpoints and steps you took so that you can relate CPU and memory consumption to specific sections of code:<\/p>\n

\"Timeline<\/a><\/p>\n

Again, if you see something that is higher than you expect, run the code multiple times to see if you get similar values. Or click on one of the break events (the rectangles) to set the selected time range to that event, which is useful for viewing the detailed CPU usage information shown in the next section.<\/p>\n

If you decide to make an improvement, a few more clicks gets you a breakdown of CPU and memory usage to help identify opportunities for improvement. We\u2019ll show you how to do this next!<\/p>\n

Reducing CPU Usage<\/h2>\n

When you identify a spike in CPU usage, your first instinct might be to try out a few code alternatives and see which ones use the least amount of CPU. But if you have no idea what the problem might be, or want to verify what code path is causing an issue, click on the CPU Usage<\/b> tab in the Diagnostic Tools window, and then click CPU Profiling<\/b> to start recording the functions that are running on the CPU:<\/p>\n

\"CPU<\/a><\/p>\n

Doing this samples the call-stack on the CPU once per millisecond, which adds a small amount over performance overhead to debugging. It\u2019s generally small enough, however, that you can leave it running during your debugging sessions.<\/p>\n

The simplest way to view CPU data is to set breakpoints at the start and end of the section of code of interest, as lines 55 and 65 below. When the debugger hits line 55, press F5 to run that block of code (and notice the PerfTip that appears on line 65!):<\/p>\n

\"Setting<\/a><\/p>\n

The Diagnostic Tools window automatically sets the current time selection to the time between these two breakpoints (as if you had clicked on a break event). You can also set the time range selection by clicking and dragging on a CPU spike in the graph. In both cases, the table in the CPU usage tab shows a call-tree filtered to the selected range of time:<\/p>\n

\"CPU<\/a><\/p>\n

The call-tree provides an aggregated view of all of the recorded call stacks. You can expand the nodes in the tree to follow a series of function calls (or portion of a call stack) and see the CPU usage within that code-path under. Total CPU (ms)<\/b> shows the approximate time spent in a given function and all its parent calls; and Total CPU (%)<\/b> provides a percentage breakdown of the Total CPU (ms)<\/b> column.<\/p>\n

Here we see that we spent 1067ms in DeserializeDriversJSON<\/i> when it was called by GetDriverList<\/i>, which was in turn called by GetIndividualDriverCached<\/i>, and so on. Right-click on any function and select View Source <\/b>to examine the code and look for ways to reduce calls to that function, or reduce the number of calls it makes to other functions.<\/p>\n

Reducing Memory Consumption<\/h2>\n

To view a breakdown of memory usage, open the Memory Usage<\/b> tab in the Diagnostic Tools window and click Take Snapshot<\/b>. By taking a snapshots both before and after an increase in memory lets you to filter the view to see what changed between the two in terms of Objects<\/b> and Heap Size<\/b>:<\/p>\n

\"Comparing<\/a><\/p>\n

When you take two or more snapshots, the numbers in parenthases show the differences from the previous snapshot in the table. All the blue text are hyperlinks that open the heap view to see the full set of objects captured in that snapshot, including a Count <\/b>of objects, their Size<\/b>, and the Inclusive Size <\/b>of all instances of that type plus the size of all referenced types:<\/p>\n

\"Examining<\/a><\/p>\n

In this case, we have 100,025 DocumentResponse.Driver<\/i> objects in our heap totaling about 91MB in size.<\/p>\n

Clicking a link in the parentheses lets you analyze the differences more specifically:<\/p>\n

\"Link<\/a><\/p>\n

\"Analyzing<\/a><\/p>\n

Sorting by Inclusive Size Diff<\/b> points you to the objects responsible the memory growth between the two snapshots. In this example, the diff view shows 5 new driver objects with ~54MB of memory growth between the two snapshots. The inclusive size of DriverCache<\/i>, Dictionary<\/i>, and List<\/i> objects indicates that they are all possible culprits.<\/p>\n

When viewing managed snapshots, you can select an object to view the references to and from objects of that type. The Paths to Root<\/b> tab shows the references that other objects hold to the selected type:<\/p>\n

\"Paths<\/a><\/p>\n

Here we see that the DriverCache<\/i> object has a dictionary, which created 5 new references to driver objects between the two snapshots. To jump into DriverCache<\/i> to see what it\u2019s doing, just right-click and select Go to Definition<\/b>.<\/p>\n

The Referenced Types<\/b> tab shows objects that the selected type is referencing:<\/p>\n

\"Referenced<\/a><\/p>\n

Here we see that the Driver<\/i> objects added references to 50MB worth of byte arrays, and 2MB worth of strings between the two snapshots.<\/p>\n

Similar steps to what we\u2019ve seen here also works for C++ with some small differences. When debugging C++, first toggle the \u201cHeap Profiling\u201d button<\/a> before you can take snapshots, and instead of using the references list you can view instances of a particular type and then see the allocation stack for each instance.<\/p>\n

Learning More<\/h2>\n

These are simple ways you can measure performance and memory of your app in a few minutes the next time you\u2019re using the Visual Studio debugger. Now that you\u2019ve learned the basics, you can learn more by checking out the following posts:<\/p>\n