Как стать автором
Обновить

Комментарии 13

Что сильнее бросается в глаза, так это что MethodHandle сильно проигрывает обычному reflection. Хотя неоднократно слышал что он должен быть быстрее.
Тоже слышал, что MethodHandle очень быстр и хорошо инлайнится. Но тесты показали, что он медленнее рефлексии. Интересный момент, что при вызове MethodHandle права не проверяются, поэтому в теории возможны security leakages.
по моим тестам, в 1.8.0_60 он немножко быстрей, в 1.8.0_51 он медленней, другие jvm не проверял.
Извините, но графики ужасны:

1. они трудно читаемы — к чему указывать множествно нулей, если это в производительность, измерянная в некоторых попугаях. Думаю куда лучше бы смотрелось, если бы вынесли масштаб на ось (k, M или 103, 106)

2. тяжело сравнивать графики, когда порядок величин один и тот же: более читаемей было бы, например:
— FieldSaveAccessible jdk7/jdk 8
— FieldSaveNotAccessible jdk7/jdk 8
Т.е группировать не по jdk, а по типам доступам (классам доступа) — и вообще было бы шикарно подписать +146% у jdk8 или +30% у Навальн 7ки.

Но все равно не может не радовать напор с которым встретили релиз 8ки, и учитывая, что это первый официальный релиз — думаю, что еще не все драконы выпущены на свободы — и будет еще прирорст и в reflection!
НЛО прилетело и опубликовало эту надпись здесь
А у вас и наносекунды наносекундней.
Не интересуюсь java, но картинга в заголовке зацепила. Не подскажете исходник?
Картинка с лурка, картинки оттуда всегда цепляют :)
Спасибо за первую картинку, прям с утра настроение поднимается!
Странные результаты. Такое ощущение, что JIT не работал. Так как с JIT накладные на прямые вызовы, особенно статические вообще нуелвые и разница с reflection должн ыбтьы на порядки, а не в два раза.
Как раз таки JIT и позаботился о том, чтобы все было быстро.

Кратко о том, как он это сделал, объяснял apangin вот в этом комментарии: habrahabr.ru/post/119820/#comment_3921481
Странные графики получились в тестах на доступ к полю объекта.

У поля мы проставили accessible = true и тем самым просто отключили проверки при вызове Field.get(Object). Исходя из графиков, в тестах на JDK 8 есть прирост в производительности, но за счёт чего это прирост? Если бегло просмотреть исходники, то в данном случае в качестве FieldAccessor будет использован UnsafeObjectFieldAccessorImpl, который в свою очередь вызывает unsafe.getObject(obj, offset), а там уже нативный метод из unsafe.cpp. Различий между классами JDK 7 и JDK 8 выполняющими вызов в данном случае — нет. Есть минорные изменения в unsafe.cpp, но там просто убрали assert.

Если же рассмотреть тест с accessible = false, то где тот же самый прирост производительности, как и в случае с accessible = true? Исходя из графиков получается, что в JDK 8 проверки стали медленнее, хотя сами они не менялись :)

Я наверное полную шизу написал, поэтому если что не так, то прошу поправить :)
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.