Hi,

We will soon be adding a comparison between .NET Memory Profiler and CLR
Profiler to our website, but I have written down a couple of reasons for
using .NET Memory Profiler:

--- Better overview of heap information
Using .NET Memory Profiler it is easier to get an overview of the instances
on the heap. The main view shows summary information for all the classes in
the profiled process. From this view you can show details about a selected
class and the details about a particular instance.

--- Flexible comparison of snapshots
Comping snapshot is a very efficient way of detecting memory leaks. .NET
Memory Profiler allows you to collect and save snapshot, and you can select
any two snapshots to be compared. If a suspected memory leak is detected,
then you can easily show the details of one of the instances that has not
been correctly garbage collected.

--- Instance details, including field values
.NET Memory Profiler allows you to show details about each instance on the
heap, which includes information about the call stack of the instance, all
the root paths of the instance, references to and from the instance, and
even the field values of the instance.

--- Identification of roots
.NET Memory Profiler presents all the root paths for a selected instance,
showing the shortest root path first. Additionally if the root is a static
field, local variable or method argument (which is almost always the case)
it is identified using the debugger interfaces. By identifying roots, the
root paths are much more specific when telling you what is holding on to an
instance.
Even though CLR Profiler can show the root paths, it won't give you the root
path of a specific instance. Instead it groups them together using some
algorithm (which is unknown to me).  And it will not identify any local
variables, method arguments or static fields.

--- Native memory
.NET Memory Profiler also presents information about the native memory used,
by the profiled process and any other process on the computer.  The native
memory information tells you how memory is used by the process, and how
memory is shared between processes.

--- Collect realtime data
.NET Memory Profiler presents data about the heap in real-time, both
graphically and numerically. The real-time data includes summary information
about the garbage collector, as well as information about each class. Some
of the information presented by the real-time view of .NET Memory Profiler
can be extracted from the timeline view of CLR Profiler, for instance the
total number of bytes on the heap. However, the CLR Profiler graph is NOT
presented in real-time, is much harder to read, is divided into several
heaps, and is presented using memory addresses rather than instance sizes.
Admittedly, some people may want to know exactly where in memory the
instances are located, which is information .NET Memory Profiler does not
provide.
Comparing Total bytes and Live bytes gives a very good overview of how well
the GC heap is utilized. Information about live bytes is not provided by the
timeline view of CLR Profiler and thus, it is harder to see how well the GC
heap is utilized.

--- Dispose tracker
Forgetting to dispose instances of disposable classes can have several
consequences, for instance running out of unmanaged resources, hanging on to
a resource for to long (e.g. a file handle), memory leaks and bad
utilization of the heap.
The dispose tracker helps you identify disposable instances that have not
been properly disposed, it also shows you instances that have been disposed
but not yet garbage collected. Instances that have been disposed but not
garbage collected might indicate a memory leak.

-- Call stacks/Methods
This is another view of .NET Memory Profiler. It presents information about
all the call stacks in which an allocation has occurred. The call stack is
presented at a user-definable depth. When using a depth of 1, a special
method view is used to present the methods of the process. Information prese
nted for each call stack includes: the number of bytes allocated, the number
of live instances, the number of undisposed instances etc. Additionally,
detailed information about each class on which allocations have been
performed is included. It is also possible to filter and sort the callstacks
based on criteria such as allocs/sec, live instances, undisposed instances
etc. The function graph of CLR Profiler presents information about the
number of bytes allocated by a method, but it doesn't present any additional
information. For instance, you cannot get information about allocations
performed by a specific call stack and you don't get information about which
instances are allocated by a method.

--- Higher performance
The performance of .NET Memory Profiler can be many times better the the
performance of CLR Profiler. We will make a series of performance tests of
.NET Memory Profiler and CLR Profiler, in order to present information about
the impact of the profiler. Preliminary tests using Application Center Test
on .NET Petshop, give the following numbers:

No profiler active: ~500 RPS
.NET Memory Profiler (configured to collect approximately the same data as
CLR Profiler): ~400 RPS
CLR Profiler: ~50 RPS

Having higher performance allows you to profile code in an enviroment that
more closely resembles the production environment.

--- No huge logfile created
CLR Profiler logs all activity of the profiled process into a log file. The
CLR Profiler then uses this log file to create the different views. This log
file can easily become very large, especially if the profiled process is run
for an extended period of time.
.NET Memory Profiler instead uses a set of internal structures which are
always kept up to date. The memory consumption is not affected by the number
of allocations performed or the number of methods called. Memory consumption
is affected by the number of bytes on the heap, but this number should have
an upper bound, unless there is a memory leak. Since a large log file is not
created, it is possible to run the profiler for an extended period of time.
This can for instance allow you to monitor the memory usage of a web site
over the duration of a day.
The memory used by the real-time data collected by .NET Memory profiler is
limited by a user-definable limit, which is per default set to 3 MB. When
this limit is reached, the memory usage is reduced by removing old data.
Real-time data is stored using a memory efficient delta format, which allow
real-time data to be presented for a long period of time without using too
much memory.

--- Support
.NET Memory Profiler is a supported product. The license fee includes free
support and support incidents are usually resolved within one business day.

CLR Profiler do have some views which are not included .NET Memory Profiler.
These views are omitted either because we don't think the information they
provide is useful enough (e.g histogram of ages, histogram if instance
sizes), or because we haven't collected enough information to be able to
present them. Since CLR Profiler keeps all collected data in its log file,
it can present chronological information, like the call tree view or the
timeline view. The usefulness of these views is debatable. The call tree
view can easily become too complex, and the actual memory location of
instances over time are in my opinion not very important. As previously
mentioned, the real-time data view of .NET Memory Profiler includes roughly
the same information as the timeline view, plus a lot of information not
provided by the timeline view.

Well, that was some reasons I have for preferring .NET Memory Profiler
instead of CLR Profiler. I recommend that you download and try our profiler
yourself, and then you can decide whether it's worth the license fee.

Best regards,

Andreas Suurkuusk
SciTech Software AB