Rediscover the Lost Art of Memory Optimization in Your Managed Code
Back in the old day's, when Bill Gates claimed 640 kB was all anyone would need, we had to really look at how we used memory resources in our applications. Today, it seems that nobody is really bothered with memory issues anymore. Simply add more memory, it's cheap, right? But it still pays to give attention to the use of memory when you're building an application. Thinking about how you use memory can greatly influence the performance of your application. The reason for this is very simple. If you allocate less memory, the Garbage Collector will need less time to clean up the mess you've made. Also, allocating smaller amounts of memory is faster.
I found a really good article on this topic on MSDN, written by Erik Brown.
Memory is the one resource all programs require, yet wise memory usage is becoming a lost art. Managed applications written for the Microsoft® .NET Framework rely on the garbage collector to allocate and clean up memory. For many applications, the three to five percent of CPU time spent performing garbage collection (GC) is a fair trade-off for not having to worry about memory management.
But for applications in which CPU time and memory are precious resources, minimizing the time spent garbage collecting can greatly improve application performance and robustness. If an application can more effectively use available memory, then it stands to reason that the garbage collector would run less often and for shorter periods of time. So rather than looking at what the garbage collector is or is not doing in your applications, take a look at memory usage directly.
In the article, a range of topics is coverd: the sizing of types, tools that can help you discover memory issues in your code, performance and memory benefits of pooling frequently used objects and streaming as a way to reduce the amount of memory required for processing large objects. The article also contains links to other resources about this subject. And althought the article focusses on C# development, the issues raised apply to VB.Net, managed C++, and any other .Net language.
The entire article can be found here.