Now, you can use dotMemory on ARM64 CPUs on Windows. This applies to all versions: dotMemory standalone, dotMemory in Rider, dotMemory in Visual Studio, and the dotMemory command-line tool.
Now you can run the dotMemory command-line profiler on ARM32 CPUs on Linux. The supported frameworks are .NET Core 3.1 and .NET 5.0–7.0.
In addition to Windows, dotMemory is now available for JetBrains Rider on Linux and macOS. Two new profiling modes are available in the Run widget and in the Run | Switch profiler configuration menu – Memory (sampled allocations) and Memory (full allocations). You can learn more about the differences between these in dotMemory’s Help.
You can attach the profiler to a running process from the Run menu and watch the Timeline Graph unroll in real time. Select an interval to open the Memory Allocations view, which is the same as in dotMemory Standalone. It lets you analyze allocated objects and the allocation call tree for a specific time frame.
Unfortunately, it is not yet possible to collect memory snapshots in this version.
The command-line profiler now has the
--saving-mode argument, which lets
you set conditions for when to save a dotMemory workspace.
dotMemory is now available right in JetBrains Rider:
The dotMemory plugin doesn’t allow collecting snapshots and only works on Windows in the 2022.2 release.
The dotMemory command-line tool now supports Alpine versions 3.13–3.15. The following CPUs and frameworks are supported:
When getting a snapshot with the help of the profiling API, you can now
specify a snapshot name using
The name will be shown on the dotMemory Home | Snapshots page.
You can now attach the profiler to an already running application by simply dragging the special icon onto the application window.
The dotMemory command-line tool now shows its progress when saving a snapshot.
The Similar Retention view now processes data much faster.
The dotMemory command-line tool now works on computers with Apple silicon processors. You can now use dotMemory CLT to profile .NET 6 applications (native mode) and .NET 5 applications (Rosetta 2 mode).
We completely reworked the algorithm behind the dominators tree (the object retention graph). Even if an object set contains hundreds of millions of objects, it only takes dotMemory a couple of minutes to open a specific view.
dotMemory can now get sampled data about memory allocation based on ETW events. Compared to the traditional (statistical) way of collecting allocation data, sampling is less accurate but provides a number of advantages:
Note that this feature is available only on Windows.
You can now use the Subsystems view to analyze memory allocation data. A subsystem groups all methods belonging to the same type, namespace, or assembly. The resulting view displays objects created by the subsystems and a merged call tree for each subsystem.
In this release, we have continued to improve the way you analyze memory allocation. Two new tabs have been added to the Memory Allocation view:
The search bar at the top of dotMemory views is now more flexible and easier to use:
It’s now possible to:
It’s now possible to use service messages to enable and disable the collection of memory allocation data.
A stack trace copied to the clipboard in dotMemory is now automatically opened in Rider / Visual Studio with ReSharper.
We’ve completely reworked the dotMemory Home screen – it is much easier to configure and start new profiling sessions, work with snapshots, and perform other basic operations.
Now, you can analyze dumps of .NET Core applications collected on the Linux systems
Now, dotMemory lets you analyze memory allocation on an arbitrary time interval. Just select the interval on the timeline and the Memory Allocation view will show you the objects allocated on this interval, as well as the stack trace that allocated them.
Free 30-day trial available