Существует ли максимальное количество блоков для приложения.NET?
Довольно много плагинов поддержки приложений.
Там какие-либо оборотные стороны к наличию большого количества плагинов? Существует ли зона наилучшего восприятия, вне которой существует снижение производительности, возможно?
Каково наибольшее число блоков, которые Вы видели загруженный в приложении?
6 ответов
Когда-то я работал над серверной платформой, в которой было дерево зависимостей сборки из более чем 2500 конечных точек.Это было отвратительно и заняло два часа, чтобы построить.
Поэтому, пока вы можете загружать тонны и тонны из них, приготовьтесь к тому, что люди будут указывать на вас и бросать вещи.
Я не знаю каких-либо конкретных ограничений на количество сборок. Но столкнувшись с проблемами производительности из-за множества сборок, я могу немного рассказать об этом.
Из-за различных проверок согласованности, которые CLR выполняет при загрузке сборок (например, проверка строгого имени) и вероятности того, что требуется перебазирование , очень возможно, что большое количество сборок может иметь значительную производительность. подразумеваемое.
Но если ваше приложение не требует, чтобы все сборки были загружены заранее, их разбивка на несколько сборок может фактически помочь снизить затраты на загрузку сборок на более длительный период времени вместо загрузки одной массивной сборки. впереди.
Три вещи, которые вы можете сделать, чтобы уменьшить время загрузки, если они станут проблемой:
- Сильно присвойте своим сборкам имя и поместите их в GAC во время установки.
- Запустите NGEN на сборках со строгими именами GAC в время установки
- Укажите базовый адрес, отличный от базового адреса по умолчанию для различных DLL, чтобы свести к минимуму перебазирование
Для 1 и 2 они в значительной степени идут рука об руку. Прирост производительности NGEN может быть не полностью реализован, если сборки не находятся в GAC из-за проверки строгого имени. CLR может пропустить эту проверку для сборок в GAC.
Вот отличная статья MSDN о времени запуска приложений.
Одно видимое ограничение - это использование памяти. Каждый модуль будет загружен в память. Таким образом, для 32-разрядной ОС вы получаете 1,3 ГБ, а для 64-разрядной ОС этот предел слишком велик, чтобы его можно было использовать для современных приложений.
У меня нет конкретной информации, но я вполне уверен, что у вас может быть больше сборок, чем нужно, прежде чем вы заметите какое-либо ухудшение.
Сказав это, это субъективно по отношению к нескольким другим факторам, таким как «качество» сборок, системные ресурсы и т. Д.
Я не думаю, что использование разрешающих плагинов приведет к проблемам с количеством сборок. У вас должно быть действительно убийственное приложение (например, Firefox), чтобы иметь такое количество плагинов, но в этом случае обычный пользователь не будет загружать все доступные плагины.
Проблемы с количеством сборок чаще всего вызваны слишком большой грануляцией в самом проекте. Я видел монолитное приложение, состоящее из 100 проектов Visual Studio, потому что архитектор сказал "нам нужна низкая связность". Старайтесь придерживаться правила Роя Ошерова: каждая сборка должна иметь физическую (не логическую) причину для существования. Логические проблемы лучше решать с помощью пространств имен, а не сборок.
Надеюсь, это поможет.
Нет, сладкого пятна нет. Больше кода требует больше времени для загрузки и JIT-компиляции. Но это не обязательно предсказуемо, когда это происходит, это происходит по запросу. Максимальное значение ограничено только доступным пространством виртуальной памяти на 32-разрядных машинах и размером файла подкачки на машинах x64.