Наскільки дорого коштує відображення .NET?

Я постійно чую, як погана рефлексія використовувати. Хоча я взагалі уникаю роздумів і рідко знаходжу ситуації, коли неможливо вирішити свою проблему без цього, мені було цікаво ...

Тим, хто використовував рефлексію в додатках, ви оцінювали ефективність і чи справді це так погано?

Це є. Але це залежить від того, що ви намагаєтеся зробити.

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

Однак, якщо ви відображаєте всередині серії вкладених циклів із відображенням дзвінків на кожному, я б сказав, що вам слід переглянути свій код :)

Для операцій «за кілька разів» роздуми цілком прийнятні, і ви не помітите жодних затримок або проблем з цим. Це дуже потужний механізм, і його навіть використовує .NET, тому я не розумію, чому ви не повинні спробувати.

У своїй розмові «Продуктивність повсякденних речей» Джефф Ріхтер показує, що викликати метод за допомогою рефлексії приблизно в 1000 разів повільніше, ніж називати його зазвичай.

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

Ефективність відображення буде залежати від реалізації (повторювані дзвінки повинні кешуватися, наприклад:) entity.GetType().GetProperty("PropName"). Оскільки більшість відображень, які я бачу щодня, використовуються для заповнення сутностей із зчитувачів даних або інших структур типу сховища, я вирішив орієнтувати ефективність саме на відображення, коли воно використовується для отримання або встановлення властивостей об'єктів.

Я створив тест, який, на мою думку, є справедливим, оскільки він кешує всі повторювані дзвінки і лише разів реально викликає SetValue або GetValue. Весь вихідний код для тесту на працездатність знаходиться у біт-коді за адресою: https://bitbucket.org/grenade/accessortest . Ретельний аналіз вітається і заохочується.

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

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

Якщо ви не знаходитесь у циклі, не переживайте про це.

Моїм найбільш відповідним досвідом було написання коду для порівняння будь-яких двох об'єктів даних одного типу у великій об'єктній моделі властивості. Зробив це, спробував, побіг, як собака, очевидно.

Я зневірився, а потім протягом ночі зрозумів, що без зміни логіки я можу використовувати той же алгоритм для автоматичного генерування методів для порівняння, але статичного доступу до властивостей. Для адаптації коду для цієї мети не знадобилося часу, і я мав можливість провести глибоке порівняння об'єктів зі статичним кодом, яке можна було оновлювати одним натисканням кнопки щоразу, коли модель об'єкта змінювалася.

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

Не масово. У мене ніколи не було проблем з цим у розробці настільних комп’ютерів, якщо, як стверджує Мартін, ви використовуєте його в нерозумному місці. Я чув, що багато людей мають абсолютно ірраціональні побоювання щодо її ефективності в розробці настільних ПК.

Хоча в Компактній Рамі (в якій я зазвичай є), це майже анафема, і її слід уникати, як чуми, у більшості випадків. Я все ще можу піти з його використання нечасто, але я повинен бути дуже обережним з його застосуванням, що набагато менш цікаво. :(

Це досить погано, що вам доведеться турбуватися навіть про роздуми, зроблені внутрішньо бібліотеками .NET для критичного продуктивного коду.

Наступний приклад є застарілим - істинним на той час (2008), але давно зафіксованим у новіших версіях CLR. Рефлексія взагалі все ще дещо дорога річ!

Справа в суті: Ви ніколи не повинні використовувати члена, оголошеного як "Object", у операторі lock (C #) / SyncLock (VB.NET) у високопродуктивному коді. Чому? Оскільки CLR не може заблокувати тип значення, це означає, що він повинен зробити перевірку типу відображення під час виконання, щоб побачити, чи є ваш Об’єкт насправді типом значення замість еталонного типу.

Як і у всіх випадках програмування, ви повинні збалансувати вартість продуктивності та отримати будь-яку вигоду. Рефлексія - це неоціненний інструмент при обережному використанні. Я створив бібліотеку відображення O / R в C #, яка використовувала відображення для прив'язки. Це спрацювало фантастично добре. Більшість кодів відображення було виконано лише один раз, тому будь-яке звернення до продуктивності було зовсім невеликим, але переваги були великими. Якби я писав новий алгоритм сортування, що не вдається, я б, мабуть, не використовував відображення, оскільки він, мабуть, погано масштабується.

Я вдячний, що тут я точно не відповів на ваше запитання. Моя думка, це насправді не має значення. Використовуйте рефлексію, де це доречно. Це просто ще одна мовна функція, яку потрібно навчитись як і коли користуватися.

Відображення може мати помітний вплив на продуктивність, якщо використовувати його для частого створення об’єктів. Я розробив додаток на базі Composite UI Application Block, який сильно покладається на роздуми. Була помітна деградація продуктивності, пов'язана зі створенням об'єктів за допомогою відображення.

Однак у більшості випадків немає проблем із використанням відображення. Якщо вам потрібно лише оглянути деяку збірку, я рекомендую Mono.Cecil, який дуже легкий і швидкий

Роздуми є дорогими через багато перевірок, які час виконання повинен робити, коли ви робите запит на метод, який відповідає списку параметрів. Десь глибоко всередині існує код, який перетинає всі методи для типу, перевіряє його видимість, перевіряє тип повернення, а також перевіряє тип кожного параметра. Весь цей матеріал коштує часу.

При внутрішньому виконанні цього методу існує деякий код, який робить такі речі, як перевірка, ви передали сумісний список параметрів перед виконанням фактичного цільового методу.

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

Огляньте джерело і подивіться, що робиться.

Як і у всьому, справа в оцінці ситуації. У DotNetNuke є досить основний компонент, який називається FillObjectвідображенням для заселення об'єктів з даних.

Це досить поширений сценарій, і є стаття про MSDN, що використовує Reflection для прив’язки бізнес-об'єктів до ASP.NET Form Controls, яка охоплює проблеми продуктивності.

Ефективність убік, одне, що мені не подобається у використанні рефлексії у конкретному сценарії, це те, що воно, як правило, знижує здатність зрозуміти код на швидкий погляд, що для мене не здається вартим зусиль, коли ви вважаєте, що також втрачаєте компіляцію безпека часу на відміну від сильно набраних наборів даних або чогось типу LINQ для SQL .

Роздум не різко уповільнює ефективність вашої програми. Ви можете зробити певні речі швидше, не використовуючи рефлексію, але якщо Роздум - це найпростіший спосіб досягти певної функціональності, тоді використовуйте це. Ви завжди можете рефактор, який ви кодуєте далеко від Reflection, якщо це стає проблемою Perf.

Я думаю, ви виявите, що відповідь є, це залежить. Це не велика справа, якщо ви хочете помістити це у свою програму списку завдань. Велика справа, якщо ви хочете помістити його в бібліотеку наполегливості Facebook.