Отражение производительности во время выполнения - Java против CLR
Связанный пост здесь в значительной степени установил отражение в Java как средство снижения производительности. Это относится и к CLR? (C#, VB.NET и т. д.).
РЕДАКТИРОВАТЬ: Чем отличается CLR от Java, когда дело касается отражения? Это когда-нибудь проверялось?
Ответы 3
Да, отражение в .NET также требует высокой производительности, поскольку требует запросов к таблицам метаданных в сборках.
Да. Динамическое разрешение типов и членов по имени требует их поиска в системе типов, что явно медленнее, чем статическое разрешение.
Да, это так, потому что, даже если сборки находятся в памяти, вы все равно должны просматривать таблицы метаданных, которые являются медленной частью.
Также ... как CLR сравнивается с Java, когда дело доходит до отражения?
Очень легко увидеть, что это НАМНОГО медленнее по простому фрагменту кода. Подобно тому, который вы связали для Java. Однако это действительно зависит от времени выполнения. Вы должны провести сравнительный анализ с конкретной версией среды выполнения Java и среды выполнения .NET.
Реализация Equals по умолчанию для типов значений реализована с помощью Reflection. Это работает, но чертовски медленно, и легко реализовать конкретную версию, которая намного быстрее (загвоздка в том, что вам также нужно реализовать GetHashCode). Насколько быстрее, конечно, зависит от фактического типа значения, но я видел здесь несколько огромных приростов.
Меня бы не волновала производительность создания экземпляра объекта с использованием самого отражения, а фактическая производительность методов и тому подобное, поскольку это, в конце концов, то, что я в любом случае буду использовать из класса.
Конечно, создание экземпляра занимает много времени, как можно увидеть в связанной публикации, но поскольку вы, скорее всего, используете методы объекта вместо того, чтобы просто создавать его экземпляр, вам не следует слишком беспокоиться о производительности отражения - пока вы не выполнять вызовы методов, вызывая отраженные объекты Method!
Кроме того, вам нужен только один отраженный экземпляр объекта, используйте .clone() и другие хитрые приемы, если вам нужно создать больше копий.
Что, если вы используете отражение как часть своей логики - не обязательно инстанциируя что-либо, но используя определение типа в качестве руководства - своего рода «метапрограммирование»?
Если вы не создаете экземпляры объектов, зачем вам все равно отражать их (части)? Мне было бы интересно увидеть пример того, что вы имеете в виду, если у вас есть время, пожалуйста, объясните более подробно.
Предположим, у вас есть список объектов и вы хотите изменить их значения. С помощью отражения вы можете создать единый пользовательский интерфейс, который позволит вам это сделать. Вы можете определить атрибуты для меток, максимальный размер и т. д.
Ах, верный случай такого поведения, и теперь я понимаю, о чем вы. Да, это, к сожалению, медленно, но если я правильно помню (здесь немного туманно), можно создать прокси-объект, используя java.lang.reflect.Proxy для ускорения такой функциональности, повторно используя прокси для каждого объекта в списке.
Я понимаю, что в Java это медленно, но мне любопытно, применимо ли то же самое к C#.
Это все еще верно даже после загрузки сборок в память?