Разве плохо загружать многие управляемые библиотеки DLL, не используя в них никаких типов?

Question

Предыстория: В моей компании мы разрабатываем кучу приложений, которые используют те же основные библиотеки DLL. Эти библиотеки используют IoC-контейнер Spring.net для подключения (автоматическое подключение). Все приложения используют один и тот же конфигурационный файл Spring, и этот конфигурационный файл указывает на множество классов в разных DLL. Но не все приложения нуждаются в функциональности от каждой DLL. Но из-за того, как работают IoC-контейнеры, все библиотеки DLL загружаются в Spring.net для проверки типов и проверки того, какие интерфейсы они реализуют и т. Д.

Основной вопрос: я понимаю, что лучше просто загрузить dll, который вы действительно используете. Но действительно ли это плохо для использования памяти только для загрузки управляемой DLL? Или сначала вы используете классы в dll, и они получают JIT для того, чтобы использовать больше всего памяти?

Answer 1

Действительно плохо - это сложный термин для количественной оценки, я думаю, что он зависит от масштаба вещей, в общем, я бы сказал, что если вы можете избежать загрузки ненужных вам вещей, тогда вам следует. Но, конечно, если вы используете отражение, чтобы определить, можете ли вы использовать его, вам сначала нужно загрузить его ... курица и яйцо.

Что-то следует знать, однако, после загрузки сборки в домен приложения вы не сможете выгрузить ее из этого домена приложения, однако можно динамически создавать домены приложения, загружать сборки в нее и выгружать весь домен приложения. когда вы закончите.

Answer 2

Если ни один код из сборки никогда не используется, то в конечном итоге страницы из этой сборки будут перемещены из памяти в файл подкачки в пользу активно используемых страниц. В этом случае общий долгосрочный эффект, вероятно, будет незначительным. Тем не менее, это окажет негативное влияние на время запуска.

Answer 3

Не думаю, что это так плохо. Единственная проблема заключается в том, что из-за больших метаданных и объема памяти, которое занимает ваше приложение, более вероятно, что некоторые части приложения, которые используются, будут расположены на разных страницах памяти, что может привести к некоторым утечкам производительности, но это очень низкий сегмент приложения, где этот тип вещей имеет решающее значение.

Answer 4

Конечно, загрузка библиотеки DLL без их использования приводит к более медленному запуску из-за чтения сборки с диска и проверок доказательств / безопасности. Но если память - ваша забота, вы по крайней мере можете быть уверены, что вы не будете тратить больше памяти, чем размер ваших сборок, если вы действительно не используете какие-либо типы внутри. Конечно, если эти типы указаны в конфигурации пружины, по крайней мере эти типы загружаются в память, и их статический инициализатор (если есть) будет выполнен. В редких случаях это может быть проблемой. JITing выполняется CLR для каждого метода отдельно, поэтому методы, которые вы не используете, не будут тратить процессор + память.

В любом случае вы можете разбить ваши файлы конфигурации на разделы, например, поместив все определения объектов модуля A в файл moduleA.config, все определения модуля B в файл moduleB.config и укажите только те модули для вашего конкретного приложения, которые действительно необходимы.

НТН, Эрих

P.S .: Я также хотел бы предложить вам опубликовать вопросы, относящиеся к Spring for .NET, на наших форумах сообщества - там, скорее всего, будут ответы на ваши вопросы.