Cost of a new .Net process

Question

I ask for advice on how to prove or dispel the faith that is in my team (obviously for no reason). It is believed that launching a new .Net application is expensive for memory (20 MB or higher for each process). Although I note that the application clearly does not use that much (as seen from the memory profiler), they contradict the assertion that it is not an application, but a .Net Framework runtime that consumes memory.

This is based on what they all heard somewhere, so no solid evidence exists, but the conviction is extremely rooted in the team. I googled around, but I cannot find a serious analysis of the processing costs of the .Net Framework. Although I simply cannot agree that every .Net process is expensive (although I agree to admit that I may be mistaken in this), I don’t know enough to prove my point. On the other hand, my teammates do not know enough to prove that I am wrong. Does anyone know any research / analysis on this?

Thanks.

Answer 1

Well, that’s all relative. The process on Windows as a whole is an expensive resource, but only if you compare it with an operating system such as Unix. Common Windows resource sharing rules apply to a managed process. In physical memory, there will be only one instance for the code in the CLR, the JIT compiler, and any assembly that contains all .NET framework assemblies. The Windows memory manager simply displays the same pages in all processes using these DLLs.

What is not common is private bytes, you can see this number with a tool like SysInternal Process Explorer. Large parts of private bytes in a .NET process:

• pile of garbage
• stacks used by threads, default 1 MB piece
• any static variables used by code loaded in the appdomain
• code that was just generated at the time of assembly that was not changed
• personal data for CLR and jitter.

Obviously, using ngen.exe can significantly reduce the number of private bytes if you use assembly in more than one process. AppDomain is a .NET way to reduce process costs and still achieve the isolation level that is widely used in custom CLR hosts such as ASP.NET and SQL Server. If you have the ability to run code in a thread and run it in another process, then the thread should always be selected.

Answer 2

I just started creating .NET console applications on my laptop with just Console.ReadKey() . This increased my physical memory from 2.0 GB to 2.4 GB (I only have 6 GB, so there was no memory voltage).

This is 4 MB per process - quite affordable, I would say.

In any case, the measurement of memory consumption under windows and .NET is actually the science of rockets, since there are many different types of memory that, under certain circumstances, can be shared or not.