|
|
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Как известно, oracle работает над повышением производительности java, а еще известно что написать правильно тест, чтобы сравнить производительности, бывает сложно. Но это относится к тестам в рамках одной jvm, а если мы одинаковой программой будем тестить разные jvm, то можно судить о том какая jvm лучше. Или нельзя? Когда разработчик переходит на более новую jvm, он привык надеяться, что она будет по крайней мере не хуже старой. Или если хуже, то неособо. А если сильно хуже, то нас предупредят. Но можно ли на самом деле на это надеяться? Или нельзя? Возьмем следующую программу Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. И запустим на 1.7.0_21 и тех что чуть раньше, а потом на 1.7.0_25 или тех что позже, включая текущий релиз. 1.7.0_45 test took 285ms, result is 20000000 1.7.0_40 test took 295ms, result is 20000000 1.7.0_25 test took 314ms, result is 20000000 1.7.0_21 test took 4ms, result is 20000000 1.7.0_07 test took 5ms, result is 20000000 решил и 1.6 попробовать, просто для сравнения. 1.6.0_37 test took 22ms, result is 20000000 Все jvm серверные х64. Как видно, новее - далеко это не всегда лучше. Заставить новые jdk работать со скоростью старой так и не вышло. Запускал многократно, итераций прбовал делать под тыщу... Они убили кении сломали рефлексию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 02:06 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Интересно. Попробуй поиграть с опциями Performance http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Возможно от одной минорной версии к другой менялись какие-то defaults. Плюс нужно смотреть еще и на сам компиллятор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 02:57 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapok, Выполнил на двух идентичных компьютерах, из одной партии. Это на компе коллеги 1.7.0_111.7.0_11 test took 208ms, result is 1000000 1.7.0_11 test took 197ms, result is 2000000 1.7.0_11 test took 57ms, result is 3000000 1.7.0_11 test took 4ms, result is 4000000 1.7.0_11 test took 5ms, result is 5000000 1.7.0_11 test took 6ms, result is 6000000 1.7.0_11 test took 5ms, result is 7000000 1.7.0_11 test took 4ms, result is 8000000 1.7.0_11 test took 12ms, result is 9000000 1.7.0_11 test took 14ms, result is 10000000 1.7.0_11 test took 13ms, result is 11000000 1.7.0_11 test took 5ms, result is 12000000 1.7.0_11 test took 5ms, result is 13000000 1.7.0_11 test took 4ms, result is 14000000 1.7.0_11 test took 5ms, result is 15000000 1.7.0_11 test took 5ms, result is 16000000 1.7.0_11 test took 5ms, result is 17000000 1.7.0_11 test took 5ms, result is 18000000 1.7.0_11 test took 5ms, result is 19000000 1.7.0_11 test took 5ms, result is 20000000 А это на своем собственном 1.7.0_251.7.0_25 test took 180ms, result is 1000000 1.7.0_25 test took 178ms, result is 2000000 1.7.0_25 test took 174ms, result is 3000000 1.7.0_25 test took 168ms, result is 4000000 1.7.0_25 test took 167ms, result is 5000000 1.7.0_25 test took 168ms, result is 6000000 1.7.0_25 test took 168ms, result is 7000000 1.7.0_25 test took 167ms, result is 8000000 1.7.0_25 test took 167ms, result is 9000000 1.7.0_25 test took 165ms, result is 10000000 1.7.0_25 test took 166ms, result is 11000000 1.7.0_25 test took 165ms, result is 12000000 1.7.0_25 test took 165ms, result is 13000000 1.7.0_25 test took 165ms, result is 14000000 1.7.0_25 test took 166ms, result is 15000000 1.7.0_25 test took 165ms, result is 16000000 1.7.0_25 test took 165ms, result is 17000000 1.7.0_25 test took 166ms, result is 18000000 1.7.0_25 test took 166ms, result is 19000000 1.7.0_25 test took 165ms, result is 20000000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 09:51 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Я на 95% уверен, что ничего не сломано, а, как уже было сказано выше, просто сменились какие-то дефолты. Поищите на Хбаре - там была статейка о том, как распечатать на бегущей JVMке значения всех ее ключей. Потом сравните эти ключики там и там. Так же могли измениться какие-нибудь стратегии по оптимизациям. Можно посмотреть на оутпут компилятора, можно посмотреть на то, не подключаются ли какие-нибудь интринсики, и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 10:01 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
WGAВряд ли в реальной жизни Вы будете одну и ту же простейшую задачку выполнять более десяти раз подряд. Так что если судить по первым итерациям, то JVM 1.7.0_25 лучше 11-й... Там миллион каллбеков. В таком кейсе если это действительно бутылочное горло в софте то оптимизируют не сам каллбек а код в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 12:46 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapokОни убили кении сломали рефлексию. По логам видно, что отключили какую-то jit-оптимизацию, применявшуюся при большом количестве повторений. Скорее всего, наткнулись на случай, когда она приводила к ошибкам. Вообще-то если вам нужна скорость, то попытайтесь обойтись без рефлексии. Есть же всякие паттерны типа double dispatch. Если не получится, то можно в прямо в памяти соорудить промежуточный класс с вызовом нужного метода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:09 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapok, У Sun (теперь уже у оракла) есть громадный тестовый фреймворк на тестирование Java, как функциональное, так, я подозреваю, и производительности. Вот его и гоняют на всех реализациях. Что касается производительности reflection -- его вообще обсуждать нет смысла. Relection заведомо непроизводителен. Но иногда полезен, за чем он и существует. Для тестирования его на производительность, я уверен, у соотв. людей есть соотв. проверенные и сертифицированные тесты. Тебе об этом думаю беспокоиться не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:18 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
И зачем константа "12345" передаётся? Как она участвует в тесте? Как балласт чтоли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:21 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
По-моему тест скорее показывает не время вызова метода через reflection, а как быстро jit догадается что незачем 1000000 раз инкрементировать поле, а можно просто прибавить к нему 1000000 (О чём говорит время в 0ms в режиме server'а). Прогнал этот тест (убрал правда String параметр из метода) на одном и том же железе. Перед тем как прогонять тест откатывал Acronis'ом систему (winXP sp3 x86, где нет ничего кроме драйверов и текстового редактора) ставил JVM (т.е. шум от других факторов должен быть минимальным). 1.7.0_09 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_09 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_10 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_10 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_11 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_11 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_21 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_21 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_25 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_25 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_40 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_40 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_45 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.7.0_45 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.8.0-ea 4_jul_2013 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.8.0-ea 4_jul_2013 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.8.0-ea 17_oct_2013 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 1.8.0-ea 17_oct_2013 -server Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:42 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Где 0 милисекунд - какой-то фейк. Вот тут уж точно его хотелось бы увидеть после JIT-обработки. Крутил -XX:CompileThreshold ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:44 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
На 1.7.0_25, 1.7.0_40 и 1.7.0_45 - на данном тесте действительно не догадывается.. maytonГде 0 милисекунд - какой-то фейк. Вот тут уж точно его хотелось бы увидеть после JIT-обработки. Крутил -XX:CompileThreshold ? Нет. Запустил с ключом -server Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:51 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Не уверен. Но кажется опция -server это просто набор пресетов для других опций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 13:53 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
mayton, Опции server и client - это выбор серверной или клиентской jvm. На видео jug кто-то говорил, что все оптимизации "нормально" делаются только на серверной машине. На клиентской много чего нету, по сути урезаный вариант, и настройки профилей тоже другие. WGA, >Вряд ли в реальной жизни Вы будете одну и ту же простейшую задачку выполнять более десяти раз подряд. Зависит что считать простейшей задачей. Метод invorke в реальной жизни может вызываться много раз при старте приложения. В том числе, десятки тысяч раз. Если так то такой чудовищный анперфомас хоть и не смерть, но очень даже заметен. Судя по тестам на 1.8 они снова это починили. Получается, что когда они это ломают, то "в реальной жизни вы вряд ли будете запускать рефлексию часто". А когда они это чинят, то "мы работаем даже над проиводительностью рефлексии". Больше всего мне это напоминает известный анекдот -- "купи слона а потом продай и почувствуй как стало легко". Кстати, печать всех флагов делается опцией -XX:+PrintFlagsFinal к ним советуют добавить -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions Я распечатал, параметры были все одинаковые кроме двух -- MaxPermSize (на 1.7.0-21 он 80мб, на 1.7.0-25 -- 170мб), и в 21 есть bool UseFastUnorderedTimeStamps я не знаю что это, но в 25 его нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 15:40 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
А, да, я перепутал. То, о чем я говорил, была статейка на тему того, как менять эти флаги в бегущей JVMке - http://habrahabr.ru/company/mailru/blog/195004/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 16:09 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapokМетод invorke в реальной жизни может вызываться много раз при старте приложения. В том числе, десятки тысяч раз. Если так то такой чудовищный анперфомас хоть и не смерть, но очень даже заметен. В отложенной оптимизации горячих циклов есть какой-то особый трезвый расчёт. Мы не тратим время на компилляций байткода в машинынй а мгновенно получаем маркер исполнения. Это весьма полезно для конструкторов и одноразовых блоков кода типа скриптов, сценариев и мастер-джобов. Если-бы мы ставили себе задачу пересобрать всё в бинарь до очень долго ожидали-бы старт веб-сервера к примеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 16:31 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapokWGA, >Вряд ли в реальной жизни Вы будете одну и ту же простейшую задачку выполнять более десяти раз подряд. Зависит что считать простейшей задачей. Метод invorke в реальной жизни может вызываться много раз при старте приложения. В том числе, десятки тысяч раз. Если так то такой чудовищный анперфомас хоть и не смерть, но очень даже заметен.Нагрузка, которую Вы предложили JVM - нетипична. Пожалуй, соглашусь, с автором rfq По логам видно, что отключили какую-то jit-оптимизацию, применявшуюся при большом количестве повторений. Скорее всего, наткнулись на случай, когда она приводила к ошибкам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 16:58 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
apangin http://habrahabr.ru/post/111897/#comment_3577272 Если вкратце, начиная с Java 1.4 применяется так называемый New Reflection, основанный на динамической генерации байткодов. Традиционно вызовы Method.invoke(), Field.getXXX() и т.п. реализовывались в виде native-методов, которые обращались к JVM, поэтому каждый такой вызов сопровождался переключением контекста Java->Native->JVM->Java, причем на каждый invoke() надо было проверять тип аргументов метода. В новом refelction, если количество вызовов Method.invoke(), Field.getXXX() и т.п. превысит определенный порог, для данного метода или поля динамически генерируется вспомогательный Java класс — аксессор, умеющий с помощью sun.misc.Unsafe напрямую обращаться к полю или вызывать Java метод, зная, какого типа должны быть его параметры, и минуя native-код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 19:36 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
chabapok, кажется мне удалось воспроизвести твою ситуацию. Думаю что там где был резкий прирост производительности работала как раз -client машина. Или ее оптимизация. Смотрим. Я добавил вывод кое-каких Sys.props. чтобы быть точным и взял две разных JVM. Пусковой скриптик. Код: powershell 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Изменённый исходник. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Отчётик. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. Вобщем JDK6-J-ракета "не взлетела". А JDK7+mixed mode оказался внезапно быстр и стремителен. И мне не удалось порулить переключением везде где хотелось на типы машин между client/mixed-mode/server/jrockit. Впрочем для теста это уже неважно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 23:04 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
mayton, просто для сведения. Для 64 битной версии клиентской jvm пока не существует, только серверная. Параметры -server, -client ничем не рулят. Насчет JRockit точно не скажу, но видимо тоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 23:46 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
ОК. Я уже было начал считать что это Windows-specific. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 01:48 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
WGA, >>>Вряд ли в реальной жизни Вы будете одну и ту же простейшую задачку выполнять более десяти раз подряд. >>Зависит что считать простейшей задачей. Метод invorke в реальной жизни может вызываться много раз при старте приложения. В том числе, десятки тысяч раз. Если так то такой чудовищный анперфомас хоть и не смерть, но очень даже заметен. > Нагрузка, которую Вы предложили JVM - нетипична. Пожалуй, соглашусь, с автором С каким из? вы и есть автор того камента про "более 10 раз подряд" А в jvm-based языках invorke разве не может использоваться повсеместно? Мне все же кажется, что это баг, а не "так задумали". Ведь посмотрете - в 1.8 судя по тестам выше оно снова быстрое! >В отложенной оптимизации горячих циклов есть какой-то особый трезвый расчёт. Мы не тратим время на компилляций байткода в машинынй а мгновенно получаем маркер исполнения Рассчет следующий: при старте приложения обычно запускается сначала часть кода выполняющая функции конфигурирования. Она отрабатывает 1 раз и больше никогда не исполняется. Такое быстрей проинтерпретировать, чем прокомпилить и и выполнить. Компиляция - дорогой процесс. Кто писал на плюсах тот знает. Кроме того, еще не собран профиль выполнения, поэтому откомпилить его можно "как-то" но эффективным это не будет. Это значит, что когда появится профиль его снова надо будет компилить. Клиентскому же приложению надо как можно быстрей запуститься и классов в нем обычно относительно много. Кто запускал шарп тот знает как задалбывает процесс компиляции при запуске. Поэтому разработчики решили на клиенте ставить compileTreshold больше. Чтобы процесс запуска не тормозила компиляция. Сервер же имеет прово запускать дольше, но ему надо работать максимально быстро, поэтому на сервере компилит раньше. (источник: видео с jug.ru плюс различные статьи) Чтобы узнать когда что компилится есть ключик -XX:+PrintCompilation Поставим этот ключик программе. (кстати да, параметр "12345" не несет нагрузки, можно выбросить, это я убрать его забыл) на "медленной" jvm 88 1 n sun.reflect.Reflection::getCallerClass (native) (static) 88 2 java.lang.reflect.Modifier::isPublic (12 bytes) 88 3 n sun.reflect.Reflection::getClassAccessFlags (native) (static) 89 4 sun.reflect.Reflection::quickCheckMemberAccess (10 bytes) 92 5 java.lang.reflect.Modifier::isProtected (12 bytes) 93 6 java.lang.reflect.Method::invoke (63 bytes) 93 7 java.lang.reflect.Method::getCallerClass (4 bytes) 93 8 java.lang.reflect.AccessibleObject::checkAccess (96 bytes) 95 9 sun.reflect.DelegatingMethodAccessorImpl::invoke (10 bytes) 98 10 javaapplication1.Test1$Incrementer::increment (11 bytes) 98 11 ! sun.reflect.GeneratedMethodAccessor1::invoke (62 bytes) 99 12 % javaapplication1.Test1::reflTest @ 19 (97 bytes) 406 12 % javaapplication1.Test1::reflTest @ -2 (97 bytes) made not entrant 1.7.0_45 test took 342ms, result is 1000000 1406 13 javaapplication1.Test1::reflTest (97 bytes) 1406 6 java.lang.reflect.Method::invoke (63 bytes) made not entrant 1417 14 java.lang.reflect.Method::invoke (63 bytes) 1418 15 % javaapplication1.Test1::reflTest @ 19 (97 bytes) 1.7.0_45 test took 314ms, result is 2000000 ... дальше ничего не компилит на "быстрой" jvm 82 1 n sun.reflect.Reflection::getCallerClass (0 bytes) (static) 82 2 java.lang.reflect.Modifier::isPublic (12 bytes) 82 3 n sun.reflect.Reflection::getClassAccessFlags (0 bytes) (static) 82 4 sun.reflect.Reflection::quickCheckMemberAccess (10 bytes) 85 5 java.lang.reflect.Modifier::isProtected (12 bytes) 86 6 java.lang.reflect.Method::invoke (63 bytes) 86 7 java.lang.reflect.AccessibleObject::checkAccess (96 bytes) 88 8 sun.reflect.DelegatingMethodAccessorImpl::invoke (10 bytes) 89 9 javaapplication1.Test1$Incrementer::increment (11 bytes) 89 10 ! sun.reflect.GeneratedMethodAccessor1::invoke (62 bytes) 90 1 % javaapplication1.Test1::reflTest @ 19 (97 bytes) 100 1 % javaapplication1.Test1::reflTest @ -2 (97 bytes) made not entrant 1.7.0_07 test took 39ms, result is 1000000 100 11 javaapplication1.Test1::reflTest (97 bytes) 100 6 java.lang.reflect.Method::invoke (63 bytes) made not entrant 108 12 java.lang.reflect.Method::invoke (63 bytes) 110 2 % javaapplication1.Test1::reflTest @ 19 (97 bytes) 1.7.0_07 test took 24ms, result is 2000000 1.7.0_07 test took 5ms, result is 3000000 ... дальше ничего не компитит Тут числа - это время и айди_компиляции, знак % это признак osr-компиляции. (То есть компилит метод и подменяет его исполнение "на лету", до того как происходит из него выход). Знак ! - признак что метод может бросать исключение,буква n - native. Как видно, компилится практически сразу и почти одинаково. То есть тут явно "отложеную компиляцию" мы прошли. Дальше можно ставить плагин hsdis и сравнивать его вывод. Но одинаковые размеры методов надоводят на мысль, что (предположительно) скомпилило оно одинаковый код, значит разница где-то в нативном коде внутри jvm. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 04:26 |
|
||
|
Производительность рефлексии
|
|||
|---|---|---|---|
|
#18+
Что-то java 7 отробатывает всё хуже.. MethodHandle и Reflection 1.7.0_21 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.7.0_21 -server Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.7.0_25 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.7.0_25 -server Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.7.0_51 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.7.0_51 -server Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. Последняя java 8, которую могу поставить на WinXP 1.8.0-ea 14_nov_2013 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 1.8.0-ea 14_nov_2013 -server Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. TestMethodHandle.java Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 21:52 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=187&tid=2127672]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
49ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
267ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 585ms |

| 0 / 0 |
