Насколько дорого стоит отражение .NET?
https://stackoverflow.com/questions/25458
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я постоянно слышу, насколько плохо использовать отражение.Хотя я вообще избегаю размышлений и редко встречаю ситуации, когда без них невозможно решить мою проблему, мне было интересно...
Для тех, кто использовал отражение в приложениях, измеряли ли вы снижение производительности и действительно ли это так плохо?
Решение
Это.Но это зависит от того, что вы пытаетесь сделать.
Я использую отражение для динамической загрузки сборок (плагинов), и его «штраф» за производительность не является проблемой, поскольку эту операцию я делаю во время запуска приложения.
Однако, если вы размышляете внутри серии вложенных циклов с вызовами отражения для каждого, я бы сказал, что вам следует вернуться к своему коду :)
Для операций «на пару раз» отражение вполне приемлемо, и вы не заметите никаких задержек или проблем с ним.Это очень мощный механизм, и он даже используется в .NET, поэтому я не понимаю, почему бы вам не попробовать его.
Другие советы
В своем выступлении Производительность повседневных дел, Джефф Рихтер показывает, что вызов метода посредством отражения в 1000 раз медленнее чем называть его обычно.
Совет Джеффа:Если вам нужно вызвать метод несколько раз, используйте отражение один раз, чтобы найти его, а затем назначьте его методу. делегат, а затем вызовите делегата.
Производительность отражения будет зависеть от реализации (повторяющиеся вызовы должны кэшироваться, например: entity.GetType().GetProperty("PropName")).Поскольку большая часть отражений, которые я вижу изо дня в день, используется для заполнения сущностей из устройств чтения данных или других структур типа репозитория, я решил оценить производительность именно по отражению, когда оно используется для получения или установки свойств объектов.
Я разработал тест, который считаю справедливым, поскольку он кэширует все повторяющиеся вызовы и только множит фактический вызов SetValue или GetValue.Весь исходный код теста производительности находится в bitbucket по адресу: https://bitbucket.org/grenade/accessortest.Проверка приветствуется и поощряется.
Вывод, к которому я пришел, заключается в том, что удаление отражений на уровне доступа к данным, который возвращает менее 100 000 строк за раз, не дает заметных улучшений производительности, если реализация отражения выполнена хорошо.
График выше демонстрирует результаты моего небольшого теста и показывает, что механизмы, превосходящие отражение, делают это заметно только после отметки в 100 000 циклов.Большинство DAL возвращают только несколько сотен или, возможно, тысяч строк за раз, и на этих уровнях отражение работает нормально.
Если вы не в курсе, не беспокойтесь об этом.
Моим наиболее подходящим опытом было написание кода для сравнения любых двух объектов данных одного типа в большой объектной модели по свойствам.Получил, попробовал, побежал как собака, очевидно.
Я был в унынии, но в одночасье понял, что, не меняя логику, я мог бы использовать тот же алгоритм для автоматической генерации методов сравнения, но со статическим доступом к свойствам.Адаптация кода для этой цели не заняла много времени, и у меня была возможность проводить глубокое сравнение сущностей по свойствам со статическим кодом, который можно было обновлять одним нажатием кнопки при каждом изменении объектной модели.
Моя точка зрения такова:В разговорах с коллегами я несколько раз указывал, что их использование отражения может заключаться в автоматической генерации кода для компиляции, а не в выполнении операций во время выполнения, и это часто стоит учитывать.
Не массово.У меня никогда не было проблем с этим при разработке для настольных компьютеров, если только, как утверждает Мартин, вы не используете его в глупом месте.Я слышал, что многие люди совершенно иррационально опасаются его эффективности при разработке настольных компьютеров.
в Компактная структура (в котором я обычно бываю), хотя это довольно много анафема и в большинстве случаев его следует избегать, как чумы.Мне все еще удается использовать его нечасто, но мне приходится быть очень осторожным с его применением, что доставляет гораздо меньше удовольствия.:(
Это настолько плохо, что вам приходится беспокоиться даже об отражении, выполняемом внутри .NET-библиотек для кода, критичного к производительности.
Следующий пример устарел — верен на тот момент (2008 г.), но давно исправлен в более поздних версиях CLR.Однако отражение в целом все еще является довольно дорогостоящей вещью!
Дело в точке:Никогда не следует использовать член, объявленный как «Объект» в инструкции блокировки (C#)/SyncLock (VB.NET) в высокопроизводительном коде.Почему?Поскольку CLR не может заблокировать тип значения, а это означает, что она должна выполнить проверку типа отражения во время выполнения, чтобы увидеть, действительно ли ваш объект является типом значения, а не ссылочным типом.
Как и во всем, что касается программирования, вам необходимо сбалансировать затраты на производительность и полученную выгоду.Размышления — бесценный инструмент, если использовать его осторожно.Я создал библиотеку сопоставления O/R на C#, которая использовала отражение для выполнения привязок.Это сработало фантастически хорошо.Большая часть кода отражения выполнялась только один раз, поэтому снижение производительности было весьма незначительным, но польза была огромной.Если бы я писал новый запутанный алгоритм сортировки, я бы, вероятно, не использовал отражение, поскольку оно, вероятно, плохо масштабировалось бы.
Я ценю, что я не совсем ответил на ваш вопрос здесь.Я хочу сказать, что это не имеет особого значения.Используйте отражение там, где это уместно.Это просто еще одна языковая функция, которую вам нужно узнать, как и когда использовать.
Отражение может оказать заметное влияние на производительность, если вы используете его для частого создания объектов.Я разработал приложение на основе Составной блок приложения пользовательского интерфейса который во многом полагается на размышления.Произошло заметное снижение производительности, связанное с созданием объектов посредством отражения.
Однако в большинстве случаев проблем с использованием отражения не возникает.Если вам нужно только осмотреть какую-либо сборку, я бы порекомендовал Моно.Сесил что очень легкий и быстрый
Отражение требует больших затрат из-за множества проверок, которые среда выполнения должна выполнять каждый раз, когда вы делаете запрос на метод, соответствующий списку параметров.Где-то глубоко внутри существует код, который перебирает все методы типа, проверяет его видимость, проверяет тип возвращаемого значения, а также проверяет тип каждого параметра.Все это требует времени.
Когда вы выполняете этот метод внутри, есть некоторый код, который выполняет такие действия, как проверка того, что вы передали совместимый список параметров, прежде чем выполнять фактический целевой метод.
Если возможно, всегда рекомендуется кэшировать дескриптор метода, если вы собираетесь постоянно использовать его повторно в будущем.Как и все хорошие советы по программированию, часто имеет смысл избегать повторений.В этом случае было бы расточительно постоянно искать метод с определенными параметрами, а затем каждый раз выполнять его.
Покопайтесь в источнике и посмотрите, что делается.
Как и во всем, все дело в оценке ситуации.В DotNetNuke есть довольно основной компонент под названием FillObject который использует отражение для заполнения объектов из строк данных.
Это довольно распространенный сценарий, и в MSDN есть статья, Использование отражения для привязки бизнес-объектов к элементам управления формой ASP.NET который охватывает проблемы с производительностью.
Помимо производительности, одна вещь, которая мне не нравится в использовании отражения в этом конкретном сценарии, заключается в том, что оно имеет тенденцию снижать способность понимать код с первого взгляда, что, на мой взгляд, не стоит затраченных усилий, если учесть, что вы также теряете компиляцию. безопасность времени в отличие от строго типизированных наборов данных или чего-то в этом роде LINQ to SQL.
Отражение не снижает резко производительность вашего приложения.Возможно, вы сможете выполнять некоторые действия быстрее, не используя отражение, но если отражение — это самый простой способ добиться некоторой функциональности, используйте его.Вы всегда можете провести рефакторинг кода, отказавшись от Reflection, если это станет проблемой производительности.
Я думаю, вы обнаружите, что ответ: это зависит.Это не имеет большого значения, если вы захотите поместить его в свое приложение списка задач.Это очень важно, если вы хотите поместить его в постоянную библиотеку Facebook.
