Так. Хотя я с Вами не согласен в понимании слова AOT, но имею что сказать о качестве оптимизации. Если сравнивать AOT и JIT, то ключевые отличия состоят вот в чём:
1. У JIT жёсткое ограничение по времени компиляции. Из-за этого часть оптимизаций неприменима (гуглите например struct-reorg gcc, в межпроцедурной версии она долгая).
2. В режиме по умолчанию JIT имеет информацию о профиле и целевой архитектуре. Но AOT её тоже может иметь, если программист заморочится, соберёт профиль и даст опцию о целевой архитектуре.
Таким образом, если искать в принципе максимальной производительности, то имхо нужно использовать AOT с перечисленными мной наворотами, а если хочется приличной производительности при минимуме усилий, то лучше JIT.

А вы учли что у jit есть разные тиры (tier)?

Так. Хотя я с Вами не согласен в понимании слова AOT, но имею что сказать о качестве оптимизации. Если сравнивать AOT и JIT, то ключевые отличия состоят вот в чём:
1. У JIT жёсткое ограничение по времени компиляции. Из-за этого часть оптимизаций неприменима (гуглите например struct-reorg gcc, в межпроцедурной версии она долгая).
2. В режиме по умолчанию JIT имеет информацию о профиле и целевой архитектуре. Но AOT её тоже может иметь, если программист заморочится, соберёт профиль и даст опцию о целевой архитектуре.
Таким образом, если искать в принципе максимальной производительности, то имхо нужно использовать AOT с перечисленными мной наворотами, а если хочется приличной производительности при минимуме усилий, то лучше JIT.

Так. Хотя я с Вами не согласен в понимании слова AOT, но имею что сказать о качестве оптимизации. Если сравнивать AOT и JIT, то ключевые отличия состоят вот в чём:
1. У JIT жёсткое ограничение по времени компиляции. Из-за этого часть оптимизаций неприменима (гуглите например struct-reorg gcc, в межпроцедурной версии она долгая).
2. В режиме по умолчанию JIT имеет информацию о профиле и целевой архитектуре. Но AOT её тоже может иметь, если программист заморочится, соберёт профиль и даст опцию о целевой архитектуре.
Таким образом, если искать в принципе максимальной производительности, то имхо нужно использовать AOT с перечисленными мной наворотами, а если хочется приличной производительности при минимуме усилий, то лучше JIT.

Вроде бы основного ограничения на время компиляции они не отменяют.

@graetestofnoldor наверное стоит немного расписать.

JIT компиляция имеет разные компиляторы C1, C2, дакже возможность декомпилировать код если что-то пошло не так.

Первые N минут программа выполняется в интерпретаторе байткода, Потом ВМ понимает что нужно компилить в нативный код, выполняется C1 компиляция.

Во время жизни вм собирает евристики  и "мониторит горячий код". Тут может начаться С2 который уже так может перемолоть код  что его человек не поймет.

Это в краце стоит поискать доклады Шипилева на эту тему

Если кратко, то оно собирает профиль и потом по профилю компилирует и иногда перекомпилирует.
Так, в хоте редактирования того сообщения потерялась основа сравнения: я сравнивал AOT и JIT с примерно одинаковым набором оптимизаций для чистоты мысленного эксперимента. Так-то ясно, что всё зависит от набора оптимизаций. И вроде бы об этом давно договорились и про конкретно javac с его малым набором оптимизаций я не спорил.
Я тут подумал и понял, что да, есть один кейс, когда JIT полезнее: когда на одном и том же коде можно в разное время собрать два очень разных профиля. В этом случае jit всё норм перекомпилирует под новый профиль, а aot будет страдать.

ну AOT и JIT тяжело сравнивать. AOT очень полезен для маложивущих програм, вот поэтому GUI на джаве не распространено.

Для сервера где приложения могут не останавливаться годами - JIT будет себя комфортней чувствовать. Но это не значит что AOT там не нужен.

Нужно выбирать инструменты исходя из задачи, @noraltavir  вроде собирал нативный бинарь с помощью GraalVM

Нет, я только читал, как это делается. Собирал что-то совсем тестовое без GUI. Собирал @Harmonizr, но у него чего-то пошло не так.

Не считая консольных утилит и чего-то с ограничением по пямяти, AOT не нужен, потому что он будет всегда проигрывать станартному JVM JIT во всем, кроме времени старта и памяти (и по пямяти еще вопрос).

ну тут вопрос про AOT vs JIT а не конкретно GUI

Было бы очень интересно посмотреть на что затрачено время. kapt мы посадили давно на диету, он уже не особо занимает время. compileKotlin намба ван таска в отчётах гредла

Обещали существенное ускорение kotlinc, остаётся только ждать

Была лекция (внутренняя) Михаила Глухих на тему оптимизаций компилятора. Там в следующей итерации скорость фронтэнда и бэкенда уже сравнимы. Улучшение раза в  полтора, если я правильно помню. Но если говорить про андроид, то я не думаю, что там kotlinc- ботлнек.

Так @themishkun как раз пишет, что компиляция котлина занимает больше всего.
Ну и не на андроиде это ещё более заметно - там больше ничего делать и не надо 😄

Так @themishkun как раз пишет, что компиляция котлина занимает больше всего.
Ну и не на андроиде это ещё более заметно - там больше ничего делать и не надо 😄

На самом деле не обязательно. Если это развесистый проект на 3000 модулей, то валидация кэшей съест достаточно много

На самом деле не обязательно. Если это развесистый проект на 3000 модулей, то валидация кэшей съест достаточно много