Ну есть такое, хотя просто для AOT можно придумать допускающий добавление кубической оптимизации критерий. Что-то типа профит от неё по execution time намного больше, чем штраф на ctime + проверка на чём-нибудь довольно крупном.

Хм... Тут да. Соглашусь с уточнением, что там ещё и по памяти можно вылететь, не только по ctime.

Не всем этот профит продать получится -- пользователи всё равно ноют про долгую компиляцию, даже не задумываясь, за что они платят.

так это неинтересно, потому что очень сильные оптимизации не нужны для маленького кода, но на большом, например: 1000 условных циклов в кубе - это уже 1000000000

все мы знаем, что язык самой быстрой компиляции - это питон

Я бы поставил на баш

надо замерить

Он на ходу интерпретируется, что мерить будешь?

время записи исходников равносильных программ в файлик

Тут как сказать... Если маленький код очень плохо сидит на кэше и весь горячий, то он прямо напрашивается на серьёзную оптимизацию.
А вот для холодного большого кода наоборот можно пожертвовать качеством оптимизаций для большей части кода, так как это в общем execution time роли особо не сыграет.
Но это всё граничные случаи. Имхо по-хорошему действительно надо настоящие межпроцедурные оптимизации делать линейной или квадратичной сложности. Ну или свести различными способами сложность хотя бы к чему-то меньше куба.

Там жертвы слишком тяжёлые

Насчёт последнего предложения - так и делают же

/cat@relaxcats_bot

/cat@relaxcats_bot

Такая лапушка

+