Memory is cheap, but not always plentiful

As Monk would say "it's a blessing and it's a curse". I'm speaking of memory management in .NET, not a TV show. But the point is the same. Something which is so helpful and at times be a real pain.

One of .NET's major advantanges for Windows developers is its ability to manage memory more readily than leaving it to the developer. The idea is that memory management including using null pointers, knowing when to "delete" unneeded memory and so on has been the bane of 'C' based developers for years. Just create an object and forget about the process of reclaiming it. You need to create an object and return it to a caller? No problem. Neither side needs to take "ownership" of the resulting object - .NET handles the tracking for you.

Sweet.

Well, not always. In real life, users do unexpected and really annoying things like opening lots of files, printing lots of large documents, and so on. These things can consume lots of object and lots of memory. Worse, since a developer has turned over the reins to memory management to .NET, when memory consumption problems do arise it can be time consumptive to find the culprits.

One of the Visual Studio .NET tools that's sorely lacking is a reference counter/viewer that shows at any point in an application life cyle what objects exist, how may references exist to them and where those references lead. It may uncover a tangled web of interlocking relationships that hogs needed memory and requires some pruning on the part of the developer.

Currently, we're using tools from Red-Gate Software to do the analysis. What're you using?

Let me know.

Posted by Mark M. Baker at 03:21 PM  Permalink