Производительность ByteBuddy в спящем режиме

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

Ожидается ли это? Тест (https://zeroturnaround.com/rebellabs/testing-the-performance-of-4-java-runtime-code-generators-cglib-javassist-jdk-proxy-byte-buddy/ ) Я обнаружил, что кажется, что bytebuddy должен быть быстрее, чем javassist.

Я что-то пропустил?


person msp    schedule 02.08.2017    source источник


Ответы (1)


После этой статьи Byte Buddy стал немного более продвинутым и добавил больше функций. Неприятным побочным эффектом добавления таких функций, конечно же, является то, что для их обработки требуется время.

Функция, которая отвечает за снижение производительности по сравнению с этой ранней версией, — это обработка информации об универсальном типе. Byte Buddy изучает универсальные типы, и просто проверка их существования требует дополнительного времени, даже если класс не является универсальным. Кроме того, чтобы учесть переопределения универсальных методов, использующих так называемые мостовые методы, Byte Buddy интерпретирует иерархию типов. cglib, который игнорирует универсальные методы, с другой стороны, может выполнять более простой анализ, но иногда ошибается при работе с мостами видимости.

Наконец, Byte Buddy, как и cglib, сталкивается с компромиссом между временем создания класса и созданием наиболее эффективного кода. Этот компромисс в значительной степени направлен на создание эффективного кода, в котором Byte Buddy приближается к базовому уровню, то есть он не добавляет никаких накладных расходов сам по себе, а только добавляет дополнительный код, что неверно для cglib.

person Rafael Winterhalter    schedule 02.08.2017