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

Question

Влияет ли размер сборки .net на производительность? Как насчет количества сборок в вашем проекте Windows Forms / Web Forms?

Answer 1

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

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

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

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

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

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

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

Answer 2

Что ж, каждый раз при загрузке сборки будет некоторое попадание из-за потери разрешения - поиск нужного файла, потенциальная проверка номера версии и т. Д. Это, скорее всего, будет в основном при запуске .

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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