Reducing memory usage of .NET applications?
- You might want to check out Stack Overflow question .NET EXE memory footprint.
- The MSDN blog post Working set != actual memory footprint is all about demystifying the working set, process memory and how to perform accurate calculations on your total in-RAM consumption.
I will not say that you should ignore the memory footprint of your application -- obviously, smaller and more efficient does tend to be desirable. However, you should consider what your actual needs are.
If you are writing a standard Windows Forms and WPF client applications which is destined to run on an individual's PC, and is likely to be the primary application in which the user operates, you can get away with being more lackadaisical about memory allocation. (So long as it all gets deallocated.)
However, to address some folks here who say not to worry about it: If you're writing a Windows Forms application which will be running in a terminal services environment, on a shared server possibly utilized by 10, 20 or more users, then yes, you absolutely must consider memory usage. And you will need to be vigilant. The best way to address this is with good data structure design and by following best practices regarding when and what you allocate.
No specific suggestions per se, but you might take a look at the CLR Profiler (free download from Microsoft).
Once you've installed it, take a look at this how-to page.
From the how-to:
This How To shows you how to use the CLR Profiler tool to investigate your application's memory allocation profile. You can use CLR Profiler to identify code that causes memory problems, such as memory leaks and excessive or inefficient garbage collection.
One thing you need to consider in this case is the memory cost of the CLR. The CLR is loaded for every .Net process and hence factors into the memory considerations. For such a simple / small program the cost of the CLR is going to dominate your memory footprint.
It would be much more instructive to construct a real application and view the cost of that compared to the cost of this baseline program.
.NET applications will have a bigger footprint compared to native applications due to the fact that they both have to load the runtime and the application in the process. If you want something really tidy, .NET may not be the best option.
However, keep in mind that if you application is mostly sleeping, the necessary memory pages will be swapped out of memory and thus not really be that much of a burden on the system at large most of the time.
If you want to keep the footprint small, you will have to think about memory usage. Here are a couple of ideas:
- Reduce the number of objects and make sure not to hold on to any instance longer than required.
- Be aware of
List<T>and similar types that double capacity when needed as they may lead to up 50% waste. - You could consider using value types over reference types to force more memory on the stack, but keep in mind that the default stack space is just 1 MB.
- Avoid objects of more than 85000 bytes, as they will go to LOH which is not compacted and thus may easily get fragmented.
That is probably not an exhaustive list by any means, but just a couple of ideas.