Насколько дорого обходится рефлексия .NET?

Это. Но это зависит от того, что вы пытаетесь сделать.

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

Однако, если вы размышляете внутри серии вложенных циклов с вызовами отражения для каждого, я бы сказал, что вам следует пересмотреть свой код :)

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

Как и во всем, все дело в оценке ситуации. В DotNetNuke есть довольно базовый компонент под названием FillObject, который использует отражение для заполнения объектов из строк данных.

Это довольно распространенный сценарий, и в MSDN есть статья Использование отражения для привязки бизнес-объектов к элементам управления формы ASP.NET, в которой рассматриваются проблемы с производительностью.

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

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

Однако в большинстве случаев проблем с использованием рефлексии не возникает. Если вам нужно только проверить какую-то сборку, я бы порекомендовал Mono.Cecil, который очень легкий и быстрый

Как и во всем, что связано с программированием, вы должны уравновешивать затраты на производительность с полученной выгодой. Отражение - бесценный инструмент при осторожном использовании. Я создал библиотеку сопоставления O / R на C#, в которой для привязки использовалось отражение. Это сработало фантастически хорошо. Большая часть кода отражения выполнялась только один раз, поэтому снижение производительности было незначительным, но преимущества были огромными. Если бы я писал новый сложный алгоритм сортировки, я бы, вероятно, не использовал отражение, поскольку он, вероятно, плохо масштабировался бы.

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

В своем выступлении Производительность повседневных вещей Джефф Рихтер показывает, что вызов метода посредством отражения - это скорее В 1000 раз медленнее, чем его обычный вызов.

Совет Джеффа: если вам нужно вызвать метод несколько раз, используйте отражение один раз, чтобы найти его, затем назначьте его делегировать, а затем вызовите делегата.

Достаточно плохо, что вы должны беспокоиться даже о внутренней рефлексии, выполняемой библиотеками .NET для кода, критичного к производительности.

Следующий пример устарел - верен в то время (2008 г.), но давно исправлен в более поздних версиях CLR. Тем не менее, отражение в целом - вещь довольно дорогостоящая!

Показательный пример: никогда не следует использовать член, объявленный как «Object» в операторе блокировки (C#) / SyncLock (VB.NET) в высокопроизводительном коде. Почему? Поскольку среда CLR не может заблокировать тип значения, это означает, что она должна выполнить проверку типа отражения во время выполнения, чтобы увидеть, действительно ли ваш объект является типом значения, а не ссылочным типом.

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

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

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

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

Однако в Компактная структура (в котором я обычно участвую) это в значительной степени анафема, и в большинстве случаев его следует избегать, как чумы. Я все еще могу использовать его нечасто, но я должен быть очень осторожен с его применением, что гораздо менее увлекательно. :(

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

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

Если вы не в курсе, не беспокойтесь об этом.

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

Когда вы выполняете этот метод внутри, есть некоторый код, который выполняет такие вещи, как проверка, что вы передали совместимый список параметров перед выполнением фактического целевого метода.

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

Покопайтесь в источнике и посмотрите, что делается.

Эффективность отражения будет зависеть от реализации (повторяющиеся вызовы должны кэшироваться, например: entity.GetType().GetProperty("PropName")). Поскольку большая часть отражений, которые я вижу ежедневно, используется для заполнения сущностей из считывателей данных или других структур типа репозитория, я решил протестировать производительность специально при отражении, когда оно используется для получения или установки свойств объектов.

Я разработал тест, который считаю справедливым, поскольку он кэширует все повторяющиеся вызовы и только время фактического вызова SetValue или GetValue. Весь исходный код для теста производительности находится в битовом пакете по адресу: https://bitbucket.org/grenade/accessortest. Внимательность приветствуется и поощряется.

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

График выше демонстрирует результаты моего небольшого теста и показывает, что механизмы, которые превосходят отражение, делают это заметно только после отметки в 100 000 циклов. Большинство DAL возвращают только несколько сотен или, возможно, тысяч строк за раз, и на этих уровнях отражение работает нормально.