一部のコードを最適化する方法に関する最近の議論で、コードを多数の小さなメソッドに分割するとパフォーマンスが大幅に向上すると言われました。これは、JIT コンパイラが大きなメソッドを最適化することを好まないためです。
JIT コンパイラーは、独自のメソッド内にあるかどうかに関係なく、コードの自己完結型セグメントを識別できるように思われるため、これについては確信が持てませんでした。
誰でもこの主張を確認または反論できますか?
一部のコードを最適化する方法に関する最近の議論で、コードを多数の小さなメソッドに分割するとパフォーマンスが大幅に向上すると言われました。これは、JIT コンパイラが大きなメソッドを最適化することを好まないためです。
JIT コンパイラーは、独自のメソッド内にあるかどうかに関係なく、コードの自己完結型セグメントを識別できるように思われるため、これについては確信が持てませんでした。
誰でもこの主張を確認または反論できますか?
まったく同じコードを多数の小さなメソッドに分割しただけでは、JIT にはまったく役立ちません。
より良い言い方をすれば、最新の HotSpot JVM は、小さなメソッドをたくさん書いても不利にならないということです。それらは積極的にインライン化されるため、実行時に関数呼び出しのコストを実際に支払うことはありません。これは、インターフェイス メソッドを呼び出す呼び出しなど、invokevirtual 呼び出しにも当てはまります。
私は数年前に、JVM がインライン メソッドであることを確認する方法を説明するブログ投稿を行いました。この手法は、最新の JVM にも適用できます。また、最新の HotSpot JVM が Java バイト コードをコンパイルする方法が広範囲に議論されている、invokedynamic に関連する議論を参照することも有益であることがわかりました。
I don't really understand how it works, but based on the link AurA provided, I would guess that the JIT compiler will have to compile less bytecode if the same bits are being reused, rather than having to compile different bytecode that is similar across different methods.
Aside from that, the more you are able to break down your code into pieces of sense, the more reuse you are going to get out of your code and that is something that will allow optimization for the VM running it (you are providing more schema to work with).
However I doubt it will have any good impact if you break your code down without any sense that provides no code reuse.