.NET Cross-Assembly Performance Hit

Я читаю книгу Билла Вагнера "Эффективный С#". В пункте 32 он выступает за то, чтобы разработчики создавали более мелкие, более сплоченные сборки, которые можно было бы повторно использовать с большей готовностью. Однако в том же пункте он говорит:

... Дополнительные проверки безопасности также осуществляется через границы сборок. Все код из той же сборки одинаковый уровень доверия (не обязательно те же права доступа, но тот же уровень правды). CLR выполняет некоторые проверки безопасности всякий раз, когда поток кода пересекает узел граница. Чем меньше сборка сборок программы границ, тем эффективнее он будет быть... Ни одна из этих характеристик проблемы должны отговаривать вас от разрушение сборок, которые тоже большой. Пункты исполнения второстепенный.

Мой вопрос: есть ли дополнительные проверки безопасности, выполняемые для каждого вызова метода в Foo.dll, или только при первой загрузке сборки?

Спасибо

Ответ 1

Система безопасности в .NET довольно сложна. Я не уверен, что ответ такой простой, как может показаться на первый взгляд. Даже если у вас есть одна сборка, проверки безопасности все еще выполняются. Когда вы запускаете приложение, имеющее всю логику в одном .exe, вы не обходите проверки безопасности .NET для загрузки и проверки сборки и не обходите проверки типа наследования. Однако, как только безопасность была проверена для данной области, она обычно не повторится (могут быть некоторые смягчающие обстоятельства, которые заставили бы повторную проверку доказательств).

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

Помимо базовых сборок загрузки и проверки безопасности типа, вы также можете иметь явные требования к разрешению. Пространства имен Microsoft System пронизаны проверками безопасности Demand и LinkDemand, которые подтверждают, что все вызывающие абоненты в стеке (спрос) или непосредственный вызывающий абонент (запрос на связь) имеют разрешение на выполнение вызова. (В ваш код также должны включаться такие проверки, которые были бы пригодны для подтверждения того, что у вызывающих есть соответствующее разрешение.) Эти проверки безопасности будут происходить независимо от того, где код живет... локально, в другой сборке или даже в сборке в другом домене приложения, Однако, как только вы переходите на вызовы, сделанные в других доменах приложений или процессах, или даже на сервисы и другие серверы, накладные расходы на марширование этих вызовов и создание соединений на порядок дороже.

Это даже не вся картина, когда дело доходит до безопасности .NET. Некоторые проверки безопасности являются более дорогостоящими, чем другие. Некоторые требуют учетных данных, другие требуют доказательств и т.д. Безопасность - это не то, что вы можете уклониться от нее... ее важнейшим и важным компонентом современной разработки программного обеспечения. Я бы не стал так беспокоиться о стоимости безопасности... поскольку он хорошо реализован и хорошо оптимизирован в .NET framework и CLR. Я бы постарался обеспечить правильное архивирование и организацию вашего приложения. Если разделение кода на несколько сборок логично, это уменьшает затраты на обслуживание, развертывание и рефакторинг, тогда его WELL стоит небольшая дополнительная стоимость для безопасности.

Ответ 2

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

Ответ 3

Я также прочитал отрывок в книге Билла Вагнера и имел те же сомнения относительно производительности, поэтому я сравнивал приложение, которое мы сейчас разрабатываем:

Есть несколько сотен тысяч до 3-4 миллионов звонков на один из наших классов С#.

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

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