Multiple .NET processes memory footprint

Question

I am developing an application suite that consists of several applications which user can run as needed (they can run all at the same time, or only several..).

My concern is in physical memory footprint of each process, as shown in task manager.

I am aware that Framework does memory management behind the curtains in terms that it devotes parts of memory for certain things that are not directly related to my application.

The question. Does .NET Framework has some way of minimizing memory footprint of processes it runs when there are several processes running at the same time? (Noobish guess ahead) Like, if System.dll is already loaded by one process, does framework load it for each process, or it has some way of sharing it between processes?

I am in no way striving to write as small (resource-wise) apps as possible (if I were, I probably wouldn't be using .NET Framework in the first place), but if there's something I can do something about over-using resources, I'd like to know about it.

Answer 1

The Windows operating system has a way of minimizing the memory footprint of multiple processes. It is known as paging.

Answer 2

I dont expect the .net framework to do something like this, and I like it the that way. The reason is that I wouldn't trust the .net framework to do the state management for each process. I mean, if a DLL is shared by two processes, the context and state might be different for each case, and we might need different instances.

For example, lets take the winword.exe - if two processes haev opened two different documents, there would be two instances of winword running in the memory. I wouldn't want .net f/w to meddle with that, especially when it comes to the COM world.

However, I would leave it to the DLL itself to be so intelligent, behave as a singleton if you don't want multiple instances running concurrently.

Answer 3

When NGEN is used to pre-JIT assemblies, it is done in such a way that if the same assembly is loaded into multiple processes the executable code can be shared between them (otherwise each process has to have a copy of both the original IL and the JIT-compiled code).

Most (all?) of the base libraries in the framework are NGEN compiled when the framework is installed partly for this reason (also to decrease the initial startup time of .NET applications)

Rico is the undisputed expert on this: http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Furthermore many of those pages can be shared across processes so we like to encourage putting sharable code into ngen’d images – jitted code can’t be shared.

Answer 4

The CLR and the JIT compiler are regular Windows DLLs. Only one instance of the code is loaded into virtual memory, its pages are shared by any .NET process. Their data is private to each process. The same is true for any of the assemblies in the .NET framework, they were ngen-ed when .NET was installed on the machine. It is probably not true for your own code, JIT compiled code is not sharable. There's rarely a point since you don't often run the same program more than once.

Just as .NET automatically manages memory, so does Windows. Just about the only thing you can do is force your program to get swapped out to disk often by setting Process.MaxWorkingSet. This is not wise. Minimizing your app's main window gets that done too.

As a rule of thumb, you cannot make proper decisions in your own program and guess correctly whether or not trimming the working set is wise. You don't know what other processes are running and how much RAM they need. Windows does.