Software Development

Monitor .NET application performance with the CLR Profiler

When you notice memory issues cropping up in your .NET applications, Tony Patton advises you to turn to the freely available CLR Profiler. It allows you to take a peek under the hood of .NET applications and monitor the garbage collector heap.

In the .NET Framework, memory management is supposed to be handled automatically by the system. This allows you to concentrate on the important issues of application design and development. Unfortunately, this utopia has not been completely realized as memory issues still appear in .NET-based applications. This article examines one tool—the CLR (Common Language Runtime) Profiler—that you may use to track down memory issues.

Garbage collection

The .NET platform adopted the garbage collection approach used in Java. That is, the .NET system tracks all memory blocks allocated in an application. It knows when memory is allocated and what monitors it uses. The system also knows when it is no longer used and frees it up. The garbage collector handles these tasks, but it does not totally divorce you from understanding memory allocation.

Weekly .NET tips in your inbox
TechRepublic's free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET.
Automatically sign up today!

Objects in .NET are allocated from an area of memory called the managed heap. The heap is described as managed because, after you ask it for memory, the garbage collector takes care of its cleanup.

Garbage collection begins by assuming all objects are unnecessary until proven otherwise. An object proves that it is necessary essentially by its references, or who it is referenced by. If the object is necessary, it is not part of the garbage collection cycle. On the other hand, if the object is not necessary, the object is flagged to be discarded.

While garbage collection is an automatic process, you should still be aware of how memory is utilized in an application. This allows you to decide if the application is properly using its memory and how the garbage collector is being utilized. This involves knowing the life of objects used to determine how often garbage collection is called in order for you to determine if the garbage collector is taxed.

Code profilers can help with this process by providing a peek at the inner workings of an application, allowing you to gain a better understanding of memory usage. The .NET CLR includes a profiling API that you may use to write custom profilers for managed applications. There are plenty of commercial profiler tools available, but Microsoft provides a free one called the CLR Profiler.

CLR Profiler

The download is comprised of a single installation program that places the tool on your system. In addition, extensive documentation is included. The CLR Profiler allows you to take a peek under the hood of a .NET application and see what is happening as it runs. It also lets you monitor what is happening with the garbage collector heap. By installing the CLR Profiler, you can access the following information about an application:

  • Which methods allocate which types of objects?
  • Which objects survive?
  • What is on the heap?
  • What keeps objects alive?
  • Who is calling whom how often?
  • Which methods, classes, and modules get pulled in by whom?

The data used by the CLR Profiler is stored in self-contained log files. The application provides both Windows client and command-line interfaces.

The tool does affect application performance as it churns out log data, so be careful when/if using it with applications in a production environment. In addition, the size of the log data files can become overwhelming depending on what is being logged, so be wary of disk space. Finally, the CLR Profiler starts the application it will be profiling, so you cannot attach it to currently running processes.

Running the application is easy via the Windows client interface. The simple interface allows you to start and stop profiling, as well as view the current contents of the heap. In addition, you can start and stop profiling (a good option if you're only profiling during certain operations) via a checkbox.

A log file is created once profiling has been stopped. You can see various graphs/reports called views to get an idea of memory usage by the profiled application. The views allow you to track object creation, memory consumed by objects, heap size, the type of objects created, and so forth. This is all available via graphs, so the data is friendly to the eyes (as opposed to scanning a log file).

Commercial tools

If you find that the CLR Profiler falls short in your profiling needs, there are a variety of third-party tools on the market. The following list provides a sampling of these products.

  • ANTS Profiler: It allows you to profile both desktop and Web applications, and the latest version promises Windows Vista support.
  • DevPartner Performance Analysis: It includes support for .NET as well as legacy technologies COM, COM+, and ASP.
  • NProf: An open source profiler available free of charge, but like many open source projects, the documentation is limited.

Miss a column?

Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

About

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

3 comments
wesnur
wesnur

i guess the use "cache" be a good option as well. the third party caching solutions like NCache or Velocity are there to help in this regard.

jwhite
jwhite

"Garbage collection begins by assuming all objects are unnecessary until proven otherwise." - Right. "An object proves that it is necessary essentially by its references, or who it is referenced by." - Ok, but if you're going to make the statement you could be more complete in the description. It's actually based on what's reachable from the application roots. Two objects referencing each other that aren't reachable will still be considered garbage. "On the other hand, if the object is not necessary, the object is flagged to be discarded." - Actually, objects that are reachable from the application roots are flagged, and anything not flagged is considered garbage. Remember how the GC started by asuming everything was garbage? http://msdn.microsoft.com/msdnmag/issues/1100/gci/

Tony Hopkinson
Tony Hopkinson

I'd have expected an article that covered profiling and the GC, to have a wee footnote on unsafe allocations which are also on the heap, pinning, resource allocation order and last but far from least calling the GC explicitly, all of which can have a very large impact on performance. If you don't know about them any profiling results could be misleading.

Editor's Picks