Будет ли у нас прирост производительности в Java 6, если байт-код был скомпилирован в 1.4
Я предполагаю, что существует огромная разница в производительности между Java 1.4 и Java 6 после просмотра этого документа.
Мой вопрос, будет ли Java 6 все еще иметь свое волшебство, когда байт-код, который он должен запустить, был скомпилирован в 1.4?
Некоторый фон для "почему вопрос?" здесь
4 ответа
Да, поскольку большая часть оптимизаций выполняется во время выполнения JVM, компилятор делает очень мало в отношении оптимизации. Таким образом, код, скомпилированный со старым Java-компилятором, все равно выиграет от новой JVM.
Однако во время компиляции выполняются некоторые оптимизации, такие как последовательная замена String конкатенации с StringBuilder,
Как отмечает Томаш Нуркевич, большая часть оптимизации выполняется компилятором JIT, и вы должны увидеть преимущества в производительности, запустив java 6 вместо java 1.4. Однако это не гарантирует, что вы получите лучшие результаты. Вы все еще можете упустить преимущества, если используете более медленные (более старые) варианты структур данных. например, StringBuffer вместо StringBuilder, Vector вместо LinkedList, Hashtable вместо HashMap и так далее...
Вы также можете рассмотреть возможность компиляции с флагом -deprecated для javac. Возможно, вы захотите заменить устаревшие методы, так как они обычно означают, что для достижения того же результата существует более эффективная альтернатива.
Почти все оптимизации в java происходят в jit и поэтому зависят только от версии jvm, на которой работает приложение. Компилятор байт-кода javac просто испускает максимально простые байт-коды. Я не думаю, что есть какие-либо оптимизации на этом этапе, кроме, возможно, для конкатенации строк с использованием StringBuilder / StringBuffer,
Java 6 и выше могут использовать более быстрый и простой верификатор байт-кода для классов, скомпилированных с целевой версией 6. Компилятор javac создает дополнительную информацию о типах данных в каждом слоте стека, которую верификатор должен проверить. В предыдущих версиях верификатор должен был выводить эти типы, что является более сложным. Это изменение только ускорит загрузку классов и не должно влиять на фактическое выполнение байт-кода.
Я думаю, что другое изменение в байт-коде в версии 5 или 6 состояло в том, что постоянный пул в файле классов может ссылаться на классы и интерфейсы. Опять же, это, вероятно, влияет только на загрузку классов.
Мало того, что будет просто огромный выигрыш в производительности, но даже между версиями Java 6 есть большие различия. Я отслеживал незначительные выпуски Java 6 в течение 18-месячного периода и видел ускорение на 15-20% именно от этого.
Кстати, Java 7 уже вышла и является предпочтительной производственной версией - есть ли причина, по которой вы не хотите переходить на эту версию?
Ох, и последнее. Если вам нужно доказать выгоды для управления, вам следует много узнать об измерении производительности Java-приложений. У меня есть статья в грядущем выпуске журнала Java на Oracle за май / июнь 2012 года, которая на сто процентов, если вам это нужно. Это очень скользкая тема, поэтому вы должны много читать, иначе вы можете получить очень вводящие в заблуждение цифры.