Хей, Хабр!

Твоя рефлексия всё ещё слишком медленная? Тогда мы идём к тебе!

Ищем способы ускорить рефлективные вызовы методов, сравниваем их, разбираемся, как создать свой быстрый field accessor...

Интересно? Добро пожаловать под кат!

После прочтения заголовка у среднестатистического читателя наверняка возникнет весьма логичный вопрос: «Кто такая эта ваша рефлексия и зачем её ускорять?»

И если первая часть будет волновать только совсем уж откровенных неофитов (ответ тут), то вторая точно нуждается в пояснении.

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

Однако в java рефлексия реализована не самым быстрым (зато надёжным) методом, а именно, через использование JNI-вызовов. JNI (Java Native Interface) – очень полезная штука, позволяющая машине вызывать код из «внешнего мира», библиотек, написанных на C/C++ или ассемблере.

К сожалению, нельзя просто так взять и вызвать потенциально опасный бинарь, во-первых, потенциально несовместимый с внутренним миром машины, а во-вторых, способный без угрызений совести положить всё намертво лёгким взмахом segfault’а. Поэтому непосредственно моменту прямого вызова предшествует тонна инструкций, подготовляющих обе стороны к взаимодействию. Очевидно, не самый быстрый процесс.

Тем не менее, рефлексия работает именно так: машина «выходит наружу», копается в своих внутренностях и «возвращается обратно», доставляя пользователю полученную информацию или вызывая методы/конструкторы.

А теперь представьте примерное быстродействие какого-нибудь фреймворка, который в процессе работы постоянно осуществляет рефлективные вызовы…