Je développe une suite d'applications composée de plusieurs applications que l'utilisateur peut exécuter au besoin (elles peuvent être toutes en même temps, ou seulement plusieurs ..).
Mon inquiétude est dans l'empreinte de la mémoire physique de chaque processus, comme indiqué dans le gestionnaire de tâches.
Je suis conscient que le cadre effectue la gestion de la mémoire derrière les rideaux en termes qu'il consacre des parties de la mémoire pour certaines choses qui ne sont pas directement liées à mon application.
la question. Est-ce que .NET Framework a une manière de minimiser l'empreinte mémoire des processus qu'il exécute lorsqu'il y a plusieurs processus fonctionnant en même temps? ( Noobish Guessez-vous à venir ) comme, si System.dll est déjà chargé par un processus, le cadre le charge-t-il pour chaque processus, ou a une manière de le partager entre les processus?
Je ne cherche en aucun cas écrire comme étant aussi petites (sagesse-wise) que possible (si j'étais, je n'utiliserais probablement pas .NET Framework en premier lieu), mais s'il y a quelque chose que je peux faire quelque chose À propos des ressources excessives, j'aimerais savoir à ce sujet.
4 Réponses :
Le système d'exploitation Windows a un moyen de minimiser l'empreinte mémoire de plusieurs processus. Il est connu sous le nom la pagination .
Je ne me souvenais pas de ce terme. Merci!
Je ne m'attends pas à ce que le framework .NET fasse quelque chose comme ça, et j'aime bien la telle façon. La raison en est que je ne ferais pas confiance au cadre .NET pour faire la gestion de l'État pour chaque processus. Je veux dire, si une DLL est partagée par deux processus, le contexte et l'état pourraient être différents pour chaque cas, et nous pourrions avoir besoin d'instances différentes.
Par exemple, prenons le winword.exe - si deux processus HaeV ont ouvert deux documents différents, il y aurait deux instances de WinWord en cours d'exécution dans la mémoire. Je ne voudrais pas que .net f / w se mêle à cela, surtout quand il s'agit du monde COM.
Cependant, je laisserais cela à la DLL elle-même être tellement intelligente, se comporter comme un singleton si vous ne voulez pas que plusieurs instances fonctionnent simultanément.
Lorsque NGen est utilisé dans les assemblages pré-jit, il est fait de manière à ce que le même assemblage soit chargé dans plusieurs processus, le code exécutable puisse être partagé entre eux (sinon, chaque processus doit avoir une copie des deux Original IL et le code JIT-compilé).
La plupart (tous?) des bibliothèques de base dans le cadre sont compilés Ngen lorsque le cadre est installé partiellement pour cette raison (également pour réduire le temps de démarrage initial des applications .NET)
Rico est l'expert incontesté à ce sujet: http: //blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx
En outre, plusieurs de ces pages peuvent être partagées à travers les processus, nous aimons donc encourager la mise en place de code partage dans les images Ngen'D - Le code Just ne peut pas être partagé.
Le CLR et le compilateur JIT sont des dlls Windows réguliers. Une seule instance du code est chargée dans une mémoire virtuelle, ses pages sont partagées par n'importe quel processus .NET. Leurs données sont privées à chaque processus. Il en va de même pour l'un des assemblages de la structure .NET, ils étaient Ngen-ed lorsque .NET a été installé sur la machine. Ce n'est probablement pas vrai pour votre propre code, le code compilé JIT n'est pas satrable. Il y a rarement un point car vous n'exécutez pas souvent le même programme plus d'une fois.
Tout comme .net gère automatiquement la mémoire, de même que les fenêtres. À peu près la seule chose que vous puissiez faire est de forcer votre programme à être échangé sur le disque souvent en définissant le processus.maxworkingSet. Ce n'est pas sage. Minimiser la fenêtre principale de votre application obtient cela aussi.
En règle générale, vous ne pouvez pas prendre de décisions appropriées dans votre propre programme et deviner correctement si la taille de l'ensemble de travail est sage ou non. Vous ne savez pas quels autres processus fonctionnent et combien de béliers dont ils ont besoin. Windows fait.