Должен ли я смотреть на байт-код, который создается компилятором java?

Question

No

• JIT-компилятор может «превратить» байт-код в нечто совершенно другое в любом случае.
• Это приведет вас к преждевременной оптимизации.

Yes

• Вы не знаете, какой метод будет составлен JIT, так что лучше, если оптимизировать их всех.
• Это сделает вас лучшим Java-программистом.

Я спрашиваю, не зная (очевидно), поэтому не стесняйтесь перенаправлять гиперссылки JIT.

Answer 1

Да, но в определенной степени - это хорошая возможность для образования, чтобы увидеть, что происходит под капотом, но, вероятно, должно быть сделано в умеренных количествах.

Это может быть хорошо, поскольку просмотр байт-кода может помочь понять, как исходный код Java будет скомпилирован в байт-код Java. Кроме того, он может дать некоторые идеи о том, какие оптимизации будут выполняться компилятором, и, возможно, некоторые ограничения на объем оптимизации, которую может выполнить компилятор.

Например, если строка конкатенации выполняется, javac позволит оптимизировать конкатенацию в использовании StringBuilder и выполняя append методы конкатенации String с.

Однако, если конкатенация выполняется в цикле, новый StringBuilder может быть реализован на каждой итерации, что приводит к возможному снижению производительности по сравнению с вручную инстанцировании StringBuilder вне цикла, и только выполняя append S внутри цикла.

По вопросу о JIT. Компиляция «точно в срок» будет специфичной для JVM-реализации, поэтому не очень легко узнать, что на самом деле происходит с байт-кодом, когда оно преобразуется в собственный код, и, кроме того, мы не можем определить, какие части (по крайней мере, не с некоторыми инструментами JVM, чтобы увидеть, какая компиляция JIT выполняется - я не знаю каких-либо специфических особенностей в этой области, поэтому я просто размышляю.)

Это говорит о том, JVM собирается исполнять байт-код в любом случае, то, как он выполняется, более или менее непрозрачен для разработчика, и снова JVM-specific. Могут быть некоторые трюки производительности, которые одна JVM выполняет, а другая - нет.

Когда дело доходит до вопроса о создании байт-кода, оно сводится к изучению того, что на самом деле происходит с исходным кодом, когда оно скомпилировано в байт-код. Возможность видеть виды оптимизаций, выполняемых компилятором, но также понимание того, что существуют ограничения на способ выполнения компилятором оптимизаций.

Все, что сказал, я не думаю, что это действительно хорошая идея, чтобы стать навязчивыми в отношении генерации байткода и попытаться написать программы, которые будут излучать наиболее оптимизированный байт-код. Что еще более важно, так это написать исходный код Java, который читается и поддерживается другими.

Answer 2

Это зависит полностью от того, что вы пытаетесь сделать. Если вы пытаетесь оптимизировать метод/модуль, просмотр байтового кода будет пустой тратой времени. Всегда сначала создавайте профиль, чтобы узнать, где ваши узкие места, а затем оптимизируйте узкие места. Если ваше узкое место кажется настолько жестким, насколько возможно, и вам нужно сделать это быстрее, у вас может не быть выбора, кроме как переписать его в собственном коде и интерфейсе с JNI.

Попытка оптимизировать сгенерированный байт-код будет мало полезной, поскольку компилятор JIT выполнит большую работу, и у вас не будет большой идеи о том, что именно он делает.

Answer 3

Я бы так не подумал. Если вам не нужно отлаживать компилятор javac или вы хотите знать, как вопрос интереса, я не могу придумать одну вескую причину, почему кому-то будет интересно, какой байт-код будет создан.

Знание байт-кода не сделает вас лучшим программистом на Java больше, чем зная, как работает двигатель внутреннего сгорания, что сделает вас лучшим водителем.

Подумайте об абстракциях. Вам не нужно знать о действиях кварков или атомов при попытке подсчета орбит планет. Чтобы быть хорошим программистом на Java, вам, вероятно, следует узнать ... um .. Java. Да, Java, вот и все :-)

Answer 4

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

Не беспокойтесь о производительности до тех пор, пока не найдете проблемы после загрузки вашего приложения (или вся команда обслуживания клиентов вылучает вас за этот экран, который загружается навсегда). Затем, удалите узкие места и оставите остальную часть кода в покое.

Bytecode требует скромной кривой обучения для понимания. Конечно, никогда не больно учиться больше, но прагматизм предлагает отложить его до тех пор, пока это не понадобится. (И если этот момент наступит, я рекомендую найти кого-то наставника.)