.NET Framework - Frais généraux par application

Question

Est-ce que quelqu'un a des informations concrètes sur la surcharge liée à l'utilisation de .NET Framework 2.0/3.0/3.5?

Je suis surtout intéressé par le surdébit par instance et s'il existe un "coût fixe" quel que soit le nombre d'instances, par ex. dans un environnement de services Terminal Server avec 300 instances d'une application .NET Framework en cours d'exécution existe-t-il seulement 1 instance du compilateur Just-In-Time?

Ce serait génial si je reçois un algorithme d'approximation, par exemple 10 Mo par exemple + 50 Mo pour le JIT

Answer 1

Il fonctionne de la même manière exacte que le code non managé. Le CLR, le compilateur JIT et les assemblys de structure .NET sont des DLL qui sont partagées par tout processus qui exécute du code managé. Une seule copie de leur code est chargée dans la RAM, tous les processus mappent leurs pages de mémoire virtuelle à cette copie.

Le code géré a tendance à avoir plus d'octets privés que le code non géré, le type qui ne peut pas être partagé. C'est d'abord dû au compilateur JIT, il génère du code machine à la volée à des adresses qui ne seront pas les mêmes pour un processus par rapport à un autre. Et le chargeur et les tas de déchets recueillis ont tendance à être un peu costaud.

Vous supprimez le surdébit du compilateur JIT en utilisant Ngen.exe. C'est pourquoi les assemblages de framework .NET sont partagés, ils étaient Ngen-ed lorsque vous avez installé le framework sur la machine. Vous ne pouvez rien faire à propos des tas, mais ce n'est pas vraiment différent dans le code non géré.