The major new features of .NET Memory Profiler 5.7 are:
The new implementation makes use of the debugger API available in Visual Studio 2015 and later, and no longer relies on undocumented behavior that could potentially cause problems (support for Visual Studio 2012 and 2013 has been dropped in version 5.7).
The new implementation is based on the new unit test data collector (NmpDataCollector) and supports the latest releases of Visual Studio 2019 and Visual Studio 2019 Preview, as well as Visual Studio 2017 (this feature is not implemented in Visual Studio 2015).
With the new debug profiling implementation, it is now also possible to debug unit tests that run under the profiler.
NOTE! Even though the unit test profiling is based on NmpDataCollector, it is not required to install the NmpDataCollector package to run unit tests under the profiler within Visual Studio.
The screencast below shows how unit tests can be run under .NET Memory Profiler.
NmpDataCollector is a VSTest data collector that can be added to a unit test project. It is available as a NuGet package and makes it very easy to run unit tests under the profiler within the build process, e.g. a CI/CD pipeline.
For more information, see the NMP Data Collector page.
Normally the profiler will try to allow the runtime to garbage collect as many instances as possible before collecting a snapshot. This significantly reduces the risk of falsely identifying instances as memory leaks. However, when investigating and optimizing memory utilization, e.g. using the heap utilization tracker, it is better to get information about the actual memory usage at the time of the snapshot.
The new inspection snapshot will collect the memory usage information as it is, including unreachable instances and no prior garbage collection. This is the same type of snapshot that is collected when doing inspection profiling, but with all the additional information that is available for a standard snapshot, e.g. allocation call stacks.
When profiling a process running under .NET Core 3.0 or later, the profile will identify the target
Method of a delegate. This will make it
easier to identify the reason why a delegate was created or why it has not been removed. This is especially important when allocation call stack information is not available, e.g. when
attaching or investigating a memory dump file.
As part of the memory cleanup the profiler tries to perform before collecting a snapshot, it triggers the cleanup of stale data bindings in WPF. This was implemented in .NET Memory Profiler 5.5, but caused problem when profiling a WPF application running under .NET Core 3.0 or later. Now WPF cleanup is fully supported under .NET Core 3.x and .NET 5.0.
.NET 5 has introduced a new managed heap, the pinned heap, where it will place instances that are allocated as pinned (using GC.AllocateArray or GC.AllocateUninitializedArray). .NET Memory Profiler will identify instances a that are placed in this heap, using a analysis isse and in the native memory view.
To see what was new and updated in .NET Memory Profiler 5.6, see the what's new information for version 5.6.
Download .NET Memory Profiler to see how it can help you find memory leaks and optimize memory usage in your application.Download Free Trial