Est-il mauvais de charger plusieurs DLL managées sans utiliser aucun type?

Question

Contexte: Dans mon entreprise, nous développons un tas d'applications qui utilisent les mêmes dll de base. Ces dll utilisent le conteneur IoC de Spring.net pour câbler les choses (câblage automatique). Toutes les applications utilisent le même fichier de configuration de source, et ce fichier de configuration pointe vers de nombreuses classes dans de nombreuses DLL différentes. Mais toutes les applications n'ont pas besoin des fonctionnalités de toutes les DLL. Mais à cause de la façon dont les conteneurs IoC fonctionnent, toutes les DLL sont chargées pour Spring.net pour examiner les types et vérifier quelles interfaces ils implémentent et ainsi de suite.

Question de base: Je comprends qu'il est préférable de simplement charger la DLL que vous utilisez vraiment. Mais est-ce vraiment mauvais pour l'utilisation de la mémoire juste pour charger une DLL gérée? Ou est-ce d'abord que vous utilisez des classes dans la DLL et qu'ils reçoivent JIT'ed que le plus de mémoire sont utilisés?

Answer 1

Si aucun code de l'assemblage n'est utilisé, les pages de cet assemblage seront éventuellement déplacées de la mémoire dans le fichier de page en faveur des pages activement utilisées. Dans ce cas, l'effet global à long terme est susceptible d'être mineur. Bien que, il y aura un effet négatif sur le temps de démarrage.

Answer 2

Je ne pense pas que ce soit si mauvais. Le seul problème est qu'en raison des grandes métadonnées et de la quantité de mémoire que votre application prend, il est possible que certaines parties de l'application soient situées sur des pages de mémoire différentes, ce qui peut entraîner des fuites de performances. 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 alors vous devriez. Mais bien sûr, si vous utilisez la réflexion pour déterminer si vous pouvez l'utiliser, vous devez d'abord le charger ... le poulet et le problème de l'œuf. Cependant, une fois que vous chargez un assembly dans un domaine d'application, vous ne pouvez pas le décharger de ce domaine d'application. Cependant, il est possible de créer dynamiquement des domaines d'applications et de charger des assemblys dans l'application. domaine lorsque vous avez terminé.

Answer 4

Bien sûr, le chargement de dll sans les utiliser ralentit le démarrage en raison de la lecture de l'assemblage à partir du disque et des vérifications de sécurité/de preuves. Mais si la mémoire est votre préoccupation, vous pouvez au moins être sûr, vous ne perdrez pas plus de mémoire que la taille de vos assemblées 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 seront chargés en mémoire et leur initialiseur statique (le cas échéant) sera exécuté. Dans de rares cas, cela pourrait être un problème. JITing est fait par le CLR sur la base de la méthode, donc les méthodes que vous n'utilisez pas ne gaspilleront pas de CPU + mémoire.

Dans tous les cas, vous pouvez diviser vos fichiers de configuration en partitions, par ex. en mettant toutes les définitions d'objets du module A dans le fichier moduleA.config, toutes les définitions du module B dans le fichier moduleB.config et ne spécifiez que les modules réellement nécessaires pour votre application particulière.

HTH, Erich

P.S .: Je voudrais aussi suggérer que vous postez du printemps pour les questions pertinentes .NET à notre community forums - il est plus probable d'obtenir réponses à vos questions là-bas.