Стандартный компилятор Java делает некоторыми оптимизациями, но он оставляет большинство из них в JIT.
JIT знает, на каком процессоре работает программа, а также имеет доступ к информации о времени выполнения, и поэтому он может делать больше оптимизаций, чем мог бы сделать компилятор Java. Кроме того, заблаговременные расширенные оптимизации могли «частично запутать» байтовый код, что затрудняет оптимизацию JIT.
Я не знаю, что делает компилятор Google, когда он переводит ваш байт-код Java в код Dalvik - он может выполнять более широкие оптимизации.
Может быть, этот инструмент будет полезен для вас: Dalvik Optimization and Verification With dexopt
Кстати, пример вы упоминаете не всегда справедливо; преобразование a/4
в a >> 2
не гарантирует, что программа будет работать быстрее на любом процессоре. Я прочитал статью где-то однажды (извините, не могу найти ее прямо сейчас ...), которая объяснила, что на современных процессорах x86 a >> 2
может быть даже медленнее, чем a/4
.
В любом случае не делайте преждевременных оптимизаций, таких как преобразование a/4
в a >> 2
вручную в исходный код, если у вас нет реальных доказательств (из измерений производительности), что это целесообразно сделать.
Деление против левого сдвига не влияет на общую скорость программы. Не малейший бит. – delnan