Есть ли разница в скорости *генерируемого кода* между ASM и Javassist?

Я рассматриваю генерацию/модификацию байт-кода во время выполнения для проекта Java.

Два важных и до сих пор поддерживаемых API — это ASM и Javassist.

ASM является самым быстрым в генерации кода и, вероятно, самым мощным. Но он также намного менее удобен для пользователя, чем Javassist.

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

Итак, мой вопрос: вводит ли Javassist какие-то ненужные накладные расходы в байт-код, которых не было бы при использовании ASM? Или, выражаясь по-другому, работа на уровне ASM даст мне прирост скорости в сгенерированном коде по сравнению с работой с Javassist?

[EDIT] Меня интересует новейшая версия обоих инструментов, и в основном интересно посмотреть, пробовал ли кто-нибудь их оба для одной и той же проблемы и видел ли какую-либо существенную разницу в скорости результирующих классов.


java javassist
person Sebastien Diot    schedule 10.06.2012    source источник
comment
Попробуйте их оба и микросравните результаты. Кроме того, помните, что JIT может исказить менее эффективный байт-код, чтобы сделать его более эффективным в реальном использовании.   -  person Kevin Welker    schedule 10.06.2012
comment
@KevinWelker Это все равно, что сказать: найди ответ на свой вопрос, а затем скажи нам! :D Главное преимущество моего вопроса в том, что мне не нужно учить их оба! Если бы я захотел, то, конечно, сделал бы свои собственные тесты, вместо того, чтобы спрашивать здесь.   -  person Sebastien Diot    schedule 10.06.2012
comment
Предпосылка SO-вопроса заключается в том, что вы искали ответы в другом месте и не смогли их найти, и/или вы что-то пробовали и не поняли своих результатов. Я не вижу доказательств ни того, ни другого. И основной смысл предложения вам попробовать согласуется с другим моим замечанием: правильного ответа нет, потому что JIT заставит результаты различаться в зависимости от конкретной ситуации, поэтому вам нужно попробовать, чтобы узнать, что будет быстрее.   -  person Kevin Welker    schedule 11.06.2012
comment
Я искал в другом месте и не нашел ответа на него. Я также не знаю, как вы ожидаете, что я докажу вам, что я искал и ничего не нашел. Предполагать, что я не искал без доказательств (например, полезный результат появляется на первых нескольких страницах Google), это оскорбительно для ИМО. Хотя я согласен с тем, что единственный способ действительно узнать это — попробовать самому, но я ожидаю по крайней мере одну неделю работы для реализации моего решения с Javassist и две с ASM. Я думаю, что имею право спросить, есть ли у кого-нибудь еще какой-нибудь опыт, прежде чем тратить 3 недели, чтобы я мог сравнить себя, а не одного.   -  person Sebastien Diot    schedule 11.06.2012
comment
Извините, что вы чувствуете себя оскорбленным — я могу понять это, хотя это не было моим намерением. Мое техническое объяснение JIT остается в силе, и я не вижу пути его обойти.   -  person Kevin Welker    schedule 11.06.2012

Ответы (1)


arrow_upward
2
arrow_downward

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

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

В любом случае, я бы посоветовал идти по этому пути только в том случае, если вы уже пробовали подход «чистой Java» и обнаружили, что он дает неприемлемую производительность.

person Stephen C    schedule 10.06.2012
comment
+1 Мудрый ответ, даже если он на самом деле не отвечает на вопрос. Я бы, конечно, использовал самую последнюю версию этих инструментов. А код будет идти во фреймворке, так что пишу один раз и забываю. Мои проблемы могут быть решены только во время выполнения, поскольку они включают систему плагинов во время выполнения, поэтому их нельзя решить с помощью Java-кода во время компиляции. - person Sebastien Diot; 10.06.2012
comment
@SebastienDiot - я озадачен вашим последним предложением. Java отлично поддерживает плагины времени выполнения (с использованием отражения) без необходимости прибегать к манипуляциям с байт-кодом. Что особенного в вашей проблеме? - person Stephen C; 12.06.2012
comment
Я пишу 3D-игру в реальном времени, поэтому время отклика должно быть в мс. И мои объекты домена должны иметь возможность изменять тип во время выполнения, когда они обновляются/понижаются. Это возможно с композицией, но включает в себя большое количество шаблонов, которые я хочу генерировать во время выполнения, потому что игра основана на плагинах, а плагины разрабатываются игроками независимо. Игрок выбирает из репозитория плагинов, и мой фреймворк должен объединить выбранные плагины вместе во время выполнения, потому что общее количество комбинаций будет экспоненциальным, что предотвратит слияние в репозитории. - person Sebastien Diot; 12.06.2012
comment
Ну, несмотря на то, что вы сказали, я думаю, что существует большой риск того, что вы потратите большие усилия на оптимизацию, которая либо 1) не нужна вообще, либо 2) не поможет (потому что вы оптимизируете не то, что нужно). ), или 3) можно было бы сделать с таким же успехом путем тщательного проектирования на чистой Java. Я бы посоветовал сначала реализовать на чистой Java... и использовать профилирование, чтобы решить, что больше всего нуждается в оптимизации. Затем решите, что с этим делать. Возможно, вы доверяете своей интуиции больше, чем профайлеру. На вашем месте я бы не стал. - person Stephen C; 12.06.2012
comment
Сначала я выполняю ручное решение, но только для того, чтобы потом знать, как сделать это автоматически. Проблема в том, что так или иначе мне нужен связующий код, который связывает разные плагины вместе, поскольку они могут дополнять одни и те же объекты. Единственный полностью общий способ, который я нашел до сих пор, — это использовать один объект для каждого поля и для каждого метода; сущности становятся двумя картами. Это было бы слишком дорого. Я потратил недели на поиск API; нет ничего такого мелкозернистого. Короче говоря, связующий код связывает код, который не знал друг о друге во время компиляции, поэтому это нельзя сделать вручную. - person Sebastien Diot; 12.06.2012