Размер сборки .NET влияет на производительность?

Ответ 1

Из шаблонов и практик Microsoft Улучшение производительности и масштабируемости .NET-приложений Глава 5:

Предпочитают одиночные большие сборки, а не множественные Меньшие сборки

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

Накладные расходы, связанные с наличием нескольких меньших сборок, могут быть отнесены к следующему:

• Стоимость загрузки метаданных для небольших сборок.
• Прикосновение к различным страницам памяти в предварительно скомпилированных изображениях в CLR для того, чтобы для загрузки сборки (если она предварительно скомпилирована с помощью Ngen.exe).
• Время компиляции JIT.
• Проверки безопасности.

Поскольку вы платите только за страницы памяти, к которым обращается ваша программа, больше сборки предоставляют утилиту Native Image Generator (Ngen.exe) с большей шанс оптимизировать собственное изображение, которое он производит. Лучшая компоновка изображения означает что необходимые данные могут быть представлены более плотно, что, в свою очередь, означает меньшую общую страницы необходимы для выполнения задания по сравнению с тем же кодом, сборок.

Иногда вы не можете избежать расщепления сборок; например, для версий и причины развертывания. Если вам нужно отправлять типы отдельно, вам может потребоваться отдельная узлы.

Ответ 2

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

Однако я не считаю, что это сильно повлияет на "стабильную" производительность.

Ответ 3

Компактная базовая библиотека DLL всегда будет загружаться в минимальное пространство памяти размером 64 килобайта, независимо от того, насколько она мала. Таким образом, загрузка четырех отдельных 10-килограммовых DLL-библиотек обойдется вам в 256 кб на устройстве. Если вы их объединили (ILMerge), это будет стоить вам всего 64 килобайта памяти на устройстве.

Ответ 4

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

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

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

Ответ 5

Я очень сомневаюсь, что это влияет на производительность любой измеримой степени. Будет штраф за загрузку при запуске; и использование памяти, вероятно, будет увеличено на МБ или два, но кроме этого - нет. Ну, если вы сами не делаете код, который страдает из-за этого.

Тем не менее, я не видел никаких тестов, поэтому я мог ошибаться.

Ответ 6

Одна вещь, которую я знаю, повлияет на производительность по отношению к размеру сборки, по крайней мере, если размер сборки связан с количеством классов, методов и т.д.

Если вы используете отражение и используете цикл, как для всех сборок, для всех типов в этих сборках, проверьте, есть ли у них атрибуты и т.д. Это может привести к статическим конструкторам JIT и вызвать их в некоторых случаях.

А, увидел, что Джон отвечает, забыл упомянуть. JIT'ing кода будет происходить только один раз на кусок кода, конечно, поэтому, если все, что вы делаете, отражает типы и никогда не трогает их послесловие, размер сборки влияет на продолжительность этого цикла отражения, но после этого это не имеет значения.

Ответ 7

Я согласен с ответом Дэна и просто добавлю немного больше информации: вот еще одно соответствующее сообщение в блоге, чтобы поддержать эту точку зрения: http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

Ответ 8

Нет, это не влияет на

Ответ 9

Неиспользуемые локальные переменные и ненужные присваивания увеличивают размер сборки и ухудшают производительность.