views:

35

answers:

1

Does anybody have any concrete information on the overhead of using the .NET Framework 2.0/3.0/3.5?

I am mostly interested in per-instance overhead and whether there is a "fixed cost" regardless of the number of instances, e.g. in a Terminal Services environment with 300 instances of a .NET Framework application running is there only 1 instance of the Just-In-Time compiler?

It would be great if I get an approximation algorithm, eg 10mb per instance + 50mb for the JIT

+2  A: 

It works the exact same way as unmanaged code. The CLR, the JIT compiler and the .NET framework assemblies are DLLs that are shared by any process that runs managed code. Only one copy of their code is loaded in RAM, all processes map their virtual memory pages to that one copy.

Managed code tends to have more private bytes than unmanaged code, the kind that cannot be shared. That's first of all due to the JIT compiler, it generates machine code on-the-fly at addresses that won't be the same for one process vs another. And the loader and garbage collected heaps tend to be a bit beefy.

You eliminate the JIT compiler overhead by using Ngen.exe. That's why the .NET framework assemblies are shared, they were Ngen-ed when you installed the framework on the machine. You can't do anything about the heaps, but that's not really different in unmanaged code.

Hans Passant
Thank you for the pointer to NGEN
taspeotis