Memory View – Exploring .NET Memory While Debugging with Rider 2018.1

During the past few weeks, the Rider 2018.1 EAP builds came with a number of new debugger features, and today’s build is no different. Rider 2018.1 EAP adds another improvement: a Memory View that lets us explore the managed heap while debugging, allowing us to look into the memory space that is used by our application!

When the debugger hits a breakpoint, we can open the memory view in a separate tab. After clicking the grid, Rider shows us the total number of objects in the heap grouped by their full type name, the number of objects, and bytes consumed.

View memory space of a running application

The memory view keeps track of the difference in object count between breakpoints. For example, after loading a large amount of data from a JSON file, we can see the number of System.String instances went up dramatically. This gives us an idea of the memory traffic going on in our application, which could potentially influence performance.

See the number of objects changes between debugger stops

Note the default behavior is that we have to click the view between each breakpoint to update the information. From the toolbar, we can choose to automatically update our view, or choose to only show objects with a non-zero diff.

Show only non-zero diff / automatically update memory view

From the memory view, we can search for specific types. For example, we can search for Beer instances, and then double-click (or Enter) to open the list of instances, where we can inspect details of the instance or copy its value.

List object instances in memory view

We don’t have to use the memory view to navigate to instances. While debugging, we can use Alt+Enter and show instances of the current type.

Navigate to memory view and instances from editor

The memory view works with the full .NET Framework (4.5+) as well as .NET Core. Mono is not supported.

One last note: while the memory view can greatly help us to explore the effect of our code on our application’s memory space, this is not a full-blown profiler. We recommend using dotTrace and dotMemory to investigate performance and memory for .NET applications.

Give the latest Rider 2018.1 EAP build a try! We’d love to hear your feedback!

About Maarten Balliauw

Maarten Balliauw is a Developer Advocate at JetBrains, working on .NET tools. He focuses on .NET, Azure, web technologies and application performance. Maarten is a frequent speaker at various national and international events. In his free time, he brews his own beer. Follow him on Twitter or check his personal blog.
This entry was posted in How-To's and tagged , , , , , . Bookmark the permalink.

One Response to Memory View – Exploring .NET Memory While Debugging with Rider 2018.1

  1. Thomas Baer says:

    Nice! Lightweight dotMemory right in the debugger

Leave a Reply

Your email address will not be published. Required fields are marked *