We have a c# .NET app that has a footprint of about 300 MB.
My questions:
- Do you monitor the memory footprint of your applications?
- Is this 300MB footprint bad?
- Are there guidelines out there?
We have a c# .NET app that has a footprint of about 300 MB.
My questions:
Short answer:
We have only once monitored the memory usage of a WPF application, which went on to become pretty serious caused by a bug by one of our third party controls.
Since .NET offers a managed Framework, the only guideline probably is to not worry about memory as long as it does not become a concern. The GC can handle itself pretty well and as long as their is memory still available, why not use it?
So when does it become a concern? Getting out of memory exceptions could be your point when you need to start to worry. I personally have never seen that happen though.
As a rule a static memory footprint is not a problem however large it is, unless it is causing problems on the target computer. The real problem with memory is when you have memory leaks, where the memory is increasing.
The reason I never bother is that I have no idea what a good or bad memory footprint is for a particular application. I think there are better routes to identifying issues within your code than focussing on memory. In simplistic terms, if your code is well written, and you have removed unneeded references, then your memory footprint will be right.
The most important thing is that it does not grow over time. To asess this correctly, it can be useful to do some occasional forced garbage collections, preferably at a time when you expect memory use to be low.
In our GUI app, we do this when a session is closed, which is every 10 minutes or so. If people oppose forcing a GC in a release app, you can make this a debug-build only feature.
I would only worry if the memory grows over a period of time - you may need to use automated testing to repeat operations over and over again in order to expose such memory leaks (see How to test a WPF user interface?)
If you are really worried I would look into using a memory profiler such as Redgate ANTS Profiler or if you want free try CLRProfiler4; the latter is hard work to use but it will still find memory leaks with patience.