Gallery

Why collect garbage?

Posted on 23 May 2006 at 11:27

Thomas Lee demonstrates how the .NET framework is responsible for reclaiming your system's vital resources

CLR Profiler

Another tool you can use to investigate an application's garbage collection usage is the CLR Profiler, a free download from Microsoft. Its prime function is to help you understand how an application interacts with .NET's managed heap. As the Microsoft website explains, you can use this tool to learn:

who allocates what on the managed heap?

which objects survive on the managed heap?

who is holding on to objects?

what does the garbage collector do over the lifetime of

your application?

This information is of huge importance to developers, but even as an IT manager it can certainly help you to work out why certain applications aren't performing as well as possible.

You can download the CLR Profiler from download .microsoft.com. To use the CLR Profiler to profile a .NET application, just start the program, select which application to run and then run it. If it's a simple program like my S1 or S1b, this will just take a second, as there's no user interaction. CLR Profiler can be used with ASP.NET applications and also to profile GUI-based applications, but in that case you'll need to interact with the application. (Note: for reasons I'm not sure of, the version of CLR Profiler available on the Microsoft download site doesn't work properly against applications compiled with .NET 2's C# compiler, but works fine when run against .NET 1.1. I'll try to find an explanation or an updated link to a profiler that works against .NET 2.) After the application has completed, the profiler shows you how it used memory. The two screenshots above, right, show profiles for S1 and S1b - S1b is clearly doing a lot more wasted work, and with a small code change could be considerably more efficient.

Reader queries

Thanks to the many readers who've taken time to email me with questions and queries. The first query related to the web subsite I set up to support this column at www.reskit.net) - one eagle-eyed reader from Malta noted an error in a link, which is now fixed, thanks!

I received the following query after my ASP.NET column:

"Currently, I develop websites mainly with ASP and Access databases. However, my hosting company (1&1) won't support ASP.NET with an Access database. It says there's 'unmanaged code' and this is a security risk. I don't understand this; is it correct? Strange that they're okay with ASP and Access, which makes me think that ASP.NET isn't such a good platform to move to if it has more security holes than ASP. Do you think it's correct, or perhaps trying to get me to upgrade to the Microsoft SQL package, which seemingly doesn't have these problems?"

Whenever you call out to unmanaged code (that is, non-.NET code), there's a risk the code may do something naughty that wouldn't be detected and prevented by the .NET runtime. The CLR's security system, which I plan to cover in a future column, allows you to be very granular in terms of what OS resources an application is able to access. As 1&1's FAQ entry points out, the firm prohibits a wide range of things - in a shared hosting scenario, it makes sense to stop potentially dangerous things. The firm seems to want to prevent you from calling any native code, rather than suggesting that only Access is unsafe or insecure. Of course, as a fan of SQL Server, I'd suggest that's a better option for a variety of reasons, but that's another story about .NET's Code Access Security for a future column.