Cost of a new .Net Process

I seek advice on either proving or dispelling a belief that is held in my team (apparently without reason). The believe is that starting a new .Net application process is expensive memory-wise (20MB and up per-process). While I point out that the app clearly isn't using that much (as seen in the memory profiler), they counter-argue that it is not the app, but the .Net Framework's runtime that consumes the memory.

This is based on something they've all heard somewhere, so no solid proof exist, but the belief is 开发者_开发技巧extremely ingrained in the team. I've googled around, but I can't find any serious analysis of per-process cost of .Net Framework's runtime. While I simply can't accept that each .Net process is that expensive (though I'm willing to admit I may be wrong on this), I do not know enough to prove my point. My teammates on the other hand don't know enough to prove me wrong. Does anyone know of any research/analysis on the matter?

Thank you.

---

Well, it is all relative. A process in Windows is in general an expensive resource, but only if you compare it to an operating system like Unix. The normal Windows resource sharing rules are in effect for a managed process. There will only ever be one copy in physical memory for the code in the CLR, JIT compiler and any assembly that is ngen-ed which includes all of the .NET framework assemblies. The Windows memory manager simply maps the same pages in all processes that uses these DLLs.

What is not shared is the Private Bytes, you can see this number with a tool like SysInternal's Process Explorer. The bigger chunks of private bytes in a .NET process are

• the garbage collected heap
• stacks used by threads, by default 1 MB a piece
• any static variables used by the code loaded in an AppDomain
• just-in-time generated code for assemblies that weren't ngen-ed
• the private data for the CLR and the jitter.

Clearly using ngen.exe can significantly cut down on the amount of private bytes, as long as you use the assembly in more than one process. An AppDomain is .NET's way to cut down on the cost of a process and still achieve a level of isolation, used to great effect in custom CLR hosts like ASP.NET and SQL Server. If you have the option to run code in a thread vs running it in another process then a thread should always be the preferred choice.

---

I just started 100 .NET console apps on my laptop with just Console.ReadKey() in them. That increased my physical memory usage from 2.0 GB to 2.4 GB (I have 6 GB total, so no memory stress occured).

That amounts to 4 MB per process - quite affordable I would say.

Anyway, measuring memory consumption under windows and .NET actually is rocket science, as there are lots of different memory types that under certain circumstances can be shared or not.