Комментарии 14
Ждёте похвалы от простых программистов-трудяг? Дождётесь только от менеджеров..
В Gradle для решения проблемы времени старта запускается Gradle Daemon.
Там достаточно сложный configuration cache и в реализации Gradle используются возможности, которые могут быть не совместими с CDT: свои ClassLoader'ы, измененный bootstrap classpath, свой instrumentation -javaagent.
Плюс в сборке типового проекта часто используются множество изолированных Classpath у разных плагинов и тасок, они очень часто часто меняются при обновлениях плагинов или просто кода сборки.
Актуален ли вообще с Gradle CDT, ACDT, или может AOT Class Loading из Java24?
И почему allprojects + options.forkOptions.executable? С JVM Toolchains не получится завести?
С fork очень сильно просядет производительность, сомнительно, что её удастся покрыть оптимизированным быстрым стартом
Вы правы, да мы и не утверждали, что это решение универсально и ускоряет вообще все. Это еще один инструмент в копилку разработчика.
Gradle-демон штука не бесплатная. Ее надо настроить, разогреть, кеши поддерживать. В сравнении на длинной дистанции скорость сборки у демона и нативной (АОТ) версии сопоставимы, это правда. Но компиляция нескольких файлов "прямо сейчас" за счет быстрого старта проходит значительно быстрее.
Кроме того, наши измерения показывают, что при сопоставимом времени, затраченном на сборку в Gradle/Maven, AOT версия потребляет меньше CPU и памяти, а это уже существенно экономит ресурсы. На CI мы получаем 10-20% экономии по ресурсам, в зависимости от проекта.
И последнее. fork режим, если запускать оригинальный javac, действительно медленнее, АОТ версия же практически не дает просадки, а иногда и выигрывает, зависит от проекта.
Тоже замечал что fork для плагинов compiler/surefire/failsafe роняет производительность, судя по коду там достаточной большой оверхед на коммуникацию или есть еще какие-то причины?
В режиме fork запускается javac как обычное Java приложение, поэтому на каждую задачу компиляции производится "подъем" JVM. Как следствие, это дорого, и производительность проседает.
Это понятно из названия, вопрос почему AOT версия тоже иногда медленнее.
Вкратце ответ будет такой: при длительном использовании (в рамках сборочной системы), методы компилятора успевают пройти через JIT-компиляцию вместе с профилированием. Вполне возможна ситуация, когда комбинация оптимизаций в C1/C2 вместе с профилем дает более быстрый код, чем был сгенерирован AOT. По нашим замерам разница небольшая, 1-2%.
1-2% процента действительно как-то мало. На проектах типа chromium или firefox профилировка показывает прирост от 10% на разных бенчмарках (особенно выигрывают бенчмарки, замеряющие скорость обработки dom-событий в js), плюс еще 15% можно выгрызть при сборке с ключом -march=native. А у вас здесь aot и без профилировки и без сборки под конкретную архитектуру CPU, а скорее всего под дефолтный x86-64. Почему просели только на 1-2% - не понимаю
Выскажу гипотезу, что вы сравниваете несравнимое. Компилятор (а мы AOT-или именно компилятор) штука достаточно сложно оптимизируемая и имеет высокую алгоритмическую сложность. Обработка DOM в этом смысле сильно проще, поскольку это большая "развесистая" структура, где за счет оптимизации расположения узлов можно экономить на бранчах в коде. Поэтому и прирост (ну или падение) у них заметно отличаются.
Повторю, это лишь гипотеза, для подтверждения требуется эксперимент и глубокий анализ.
Если дело только в этом CRaC должен дать больший прирост производительности. Если бы еще можно было после этого сконвертировать его в GraalVM модуль :)
Я больше сравнивал с Surefire, наши попытки максимально распараллелить тесты упирались в неэффективный код плагина, разница по скорости была больше 19% от оптимизированного варианта. Разработчики сами пишут что надо переписывать коммуникацию между JVM.
Про демонов вы еще CI/CD расскажите. Там сессия закончилась - будь добр выключиться. Никаких демонов.
Это напоминает проекции Футамуры (Ершова).
Компилируем компилятор или ускоряем javac вдвое