(Почему) Отражение является настолько дорогим в .NET? [дубликат]

На SO есть несколько вопросов, которые отвечают на это по-разному.

Вот хороший вопрос IMO: Какова "стоимость" отражения в .NET?

В одной из статей, на которые ссылается автор ответа, приводится интересная информация о том, что некоторые функции отражения являются более дорогостоящими, чем другие. Например, выполнение typeof не так уж плохо, но вызов методов более затратен.

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

http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.16

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

Edit:

Ну, я думаю, что последняя часть моего ответа не обязательно верна. Во многом это зависит от того, как именно вы используете отражения. Профиль! И если вы придумаете альтернативное решение, напишите его тоже :)

Лучший ответ: общепринятая мантра не так проста, как кажется. отражение == плохая производительность в значительной степени возникла в .NET 1.0 и 1.1 и не учитывает улучшения производительности в более поздних версиях.

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

Существует множество заблуждений относительно отражения.

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

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

Я провел много тестов и измерений производительности для отражения и статических операций. У рефлексии больше работы, и она всегда медленнее. Но это нормально. «Медленнее» не означает «медленнее», это просто означает «не так быстро». Вот как это следует считать. Отражение все еще может быть быстрым, но не таким быстрым, как статическая операция. Из-за этого не следует автоматически избегать этого.

Я работал с ведущими разработчиками, которые категорически запрещали любой рефлексивный код в веб-проекте, потому что он был медленным. Но ему никогда не приходило в голову, что мы используем привязку данных NHibernate, ASP.NET и ASP.NET MVC, которые работают почти исключительно с отражающей привязкой данных.

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