Comments 8
компиляция заместа запуска в JVM
Нет, код запускается в той же JVM. Просто в тест добавится N раз вызов вашей функции, добавятся замеры, прогревы и так далее. Всё это можно закодить самостоятельно.
запуск программы в JVM приближённый к реальной
Запускать тест, что очевидно, надо в тех условиях, где он будет работать. Если в проде Linux x64 c большим объемом памяти — то именно там, а не на ARM'е.
использование каких то библиотек
Они лишь упрощают жизнь. Весь тот код, который они генерят, можно написать самостоятельно
Нет, код запускается в той же JVM. Просто в тест добавится N раз вызов вашей функции, добавятся замеры, прогревы и так далее. Всё это можно закодить самостоятельно.
понятно, спс, а есть то же самое или максимально приближённое чисто на яве?
Да-да-да, Вы полностью правы. Gradle именно его и использует, то есть создает файл, туда записывает кучу путей к jar файлам. Это баг самой JMH. Я описал лишь способ подавить её.
Более того: в самом плагине есть тоже баг, так как в classpath откуда-то попали еще зависимости с именами gradle и kotlin compiler. Последнее наводит меня на мысль, что сам classpath в принципе содержит лишнее.
Мне кажетсяя этим "грешит" в том числе и gradle плагин 'application', он генерирует файлы запуска java приложения (*.sh и *.bat) которые в Windows не работают, из-за ошибки "Input line too long". Но этого можно избежать, добавив в build.gradle нехитрую регулярку (не сильно разбираюсь в groovy, но она работает))
/* Workaround for Windows cmd "Input line too long" bug */
startScripts {
doLast {
def windowsScriptFile = file getWindowsScript()
windowsScriptFile.text = windowsScriptFile.text.replaceFirst(/set CLASSPATH=%APP_HOME%\\lib\\.+/,"set CLASSPATH=%APP_HOME%\\\\lib\\\\*;")
}
}т.е. просто заменив перечисление всех файлов в classpath на * wildcard in classpath. Кажется эту возможность добавили еще в java 6, но этот плагин по-прежнему её не использует. Возможно таким способом можно и gradle-jmh plugin "починить" ))
Измеряем скорость кода Java правильно (используя JMH)