Est-il mauvais de charger de nombreuses DLL gérées sans utiliser de types dans celles-ci?

Question

Contexte: Dans mon entreprise, nous développons de nombreuses applications qui utilisent les mêmes DLL. Ces dll utilisent le conteneur IoC de Spring.net pour câbler des choses (câblage automatique). Toutes les applications utilisent le même fichier de configuration printanier et ce fichier de configuration pointe vers de nombreuses classes dans de nombreuses dll différentes. Mais toutes les applications n'ont pas besoin de fonctionnalités de chaque DLL. Mais à cause du fonctionnement de IoC-containers, toutes les dll sont chargées pour que Spring.net examine les types et vérifie les interfaces qu’ils implémentent, etc.

.

Question fondamentale: Je comprends qu'il est préférable de simplement charger les dll que vous utilisez vraiment. Mais est-ce vraiment mauvais pour l'utilisation de la mémoire de charger une dll gérée? Ou bien est-ce d’abord que vous utilisez des classes dans la DLL et que celles-ci sont en train d’obtenir le JIT qui utilise le plus de mémoire?

Answer 1

Si aucun code de l'assembly n'est jamais utilisé, les pages de cet assemblage seront finalement déplacées de la mémoire dans le fichier de page au profit des pages utilisées activement. Dans ce cas, l’effet global à long terme sera probablement mineur. Cependant, il y aura un effet négatif sur le temps de démarrage.

Answer 2

Je ne pense pas que ce soit si grave. Le seul problème est qu’en raison de la quantité de métadonnées et de la quantité de mémoire nécessaires à votre application, il est plus probable que certaines parties de l’application en cours d’utilisation soient situées sur des pages de mémoire différentes, ce qui peut entraîner des pertes de performances, mais il s’agit d’un segment d’application très bas. ce genre de choses est critique.

Answer 3

Vraiment mauvais est un terme difficile à quantifier, je suppose que cela dépend de l’échelle des choses. En général, je dirais que si vous pouvez éviter de charger des choses dont vous n’avez pas besoin, vous devriez le faire. Mais bien sûr, si vous utilisez la réflexion pour déterminer si vous pouvez l'utiliser, vous devez d'abord la charger ... Le problème de la poule et de l'œuf.

Il faut cependant être conscient du fait qu’une fois que vous avez chargé un assemblage dans un domaine d’application, vous ne pouvez pas le décharger de ce domaine d’applications. Il est toutefois possible de créer dynamiquement des domaines d’application, de charger des assemblys et de décharger l’ensemble du domaine. lorsque vous avez terminé.

Answer 4

Bien sûr, charger les dll sans les utiliser provoque un temps de démarrage plus lent en raison de la lecture de l’assemblage à partir du disque et des vérifications de preuves / sécurité. Mais si la mémoire vous préoccupe, vous pouvez au moins en être sûr, vous ne perdrez pas plus de mémoire que la taille de vos assemblys si vous n'utilisez vraiment aucun type à l'intérieur. Bien sûr, si ces types sont spécifiés dans la configuration du ressort, au moins ces types sont chargés en mémoire et leur initialiseur statique (le cas échéant) sera exécuté. Dans de rares cas, cela peut être un problème. La méthode JIT est effectuée par le CLR, méthode par méthode, afin que les méthodes que vous n'utilisez pas ne gaspillent pas de mémoire cpu +.

Dans tous les cas, vous pouvez diviser vos fichiers de configuration en partitions, par exemple. en insérant toutes les définitions d'objet du module A dans le fichier moduleA.config, toutes les définitions du module B dans le fichier moduleB.config et en spécifiant uniquement les modules réellement nécessaires à votre application.

hth, Erich

PS: j'aimerais également vous suggérer de publier des questions pertinentes pour Spring for .NET sur nos forums de la communauté - il est plus probable que vos questions soient répondues à cet endroit.