Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.NET Framework - Per Application Overhead

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

like image 639
ta.speot.is Avatar asked Feb 20 '26 04:02

ta.speot.is


1 Answers

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.

like image 88
Hans Passant Avatar answered Feb 24 '26 15:02

Hans Passant