overheads原文はこちら。java.util.UUID::nameUUIDFromBytesの改善に関連して行った分析の一部を詳述しました)の続きです。この記事を書いている時点では、このPRはまだオープンの状態ですが、この周辺の事柄を大幅に改善するいくつかの最適化を統合しています。当時実施した解析の結果統合された初めてのPRです。#1933https://github.com/openjdk/jdk/pull/1933プロトタイプやその前に実施した解析が示唆する通り、主な改善点は、digestオブジェクトをインスタンス化するために使われるConstructorをキャッシュすることにあります。プロトタイプからの大きな違いは、ClassValueやThreadLocalにキャッシュするのではなく、java.security.Provider$Serviceオブジェクトにキャッシュする点です。これは余分なルックアップなどがないことを意味します。そのために少々利益が得られます。Objects.hashを放棄するなど、いくつかのマイナーな機能強化を追加します。Objects.hashは便利ですが、可変長配列を確保してしまいます。そのため、Objects.hashの放棄によりパフォーマンス向上が見込まれますが、いつものように、まずその重要性を確認すべきです。APIのパフォーマンスにわずかに影響を与えますが、Objects.hashの放棄は合理的なことのように思えました。全体として、MessageDigest.getInstanceの割り当てのオーバーヘッドがゼロになりました。MessageDigestだけを割り当てます。これはオペレーション毎に144バイトの割り当て圧力が減少したことを意味します。APIを使って取得される任意のセキュリティサービスも同様に改善されることを意味します。このことを反映するために機能強化のサマリーを変更するには時が経ちすぎました...。sizeMD5自体を最適化するために作成したプロトタイプ(一時的な配列を取り除き、ダイジェストを生成するためにデータを読み取るコードを、内在化により置き換えられるメソッドに入れる)はうまくいきました。improvement?https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#md5—room-for-improvementこれにより、インスタンスサイズがかなり小さくなり、内在化による最適化で除去されなかったいくつかのアクティビティを回避することで、ダイジェスト生成のパフォーマンスが少々改善されています。ダイジェスト生成対象のデータが小さいときに最も顕著です。そんなわけで、同じ(または少なくとも非常に類似した)最適化がSHAの実装のほとんどに適用できることをすぐに現実化するためだけに、プルリクエストを起草しました。#1855https://github.com/openjdk/jdk/pull/1855主な違いは、SHA実装のために最適化で除去されるべき一時的な配列がかなり大きくなっている点で、それゆえ、配列のコードを完全に削除するのは面倒なことになります。コンパイルされると、配列の割り当てが不要になることを意味します。gcを付けて実行してみると、これが効果を発揮し、アロケーションを大幅に削減できることがわかります。割り当て削減とあわせて、SHA-256やSHA-512のようなより強力なダイジェストがフットプリントのオーバーヘッドを大幅に削減することを意味します。SHA-256では半分以上、SHA-512では3分の2です。up現在に戻って、PR#1855で追加したUUID::nameUUIDFromBytesのマイクロベンチマークを実行してみると、この小さな冒険を始めた特定の操作でそれなりの利益を得ることができたことが明白です。ops/us入力の大きさに依存するとはいえ、およそ40~50%のスピードアップです。内部のより深い部分を分析して改善点を見つけようとしたことにより、セキュリティ領域全般を改善するパッチを提供できました。MD5の改善点を様々なSHA実装に変換したことも大きな成功でした。これらの改善のいくつかは、うまくいけば、いくつかの仮想的な実際のアプリで実際の利益につながることを期待しています。素晴らしいことですが、これらの改善は必ずしもjava.util.UUID::nameUUIDFromBytesのMD5オブジェクトのキャッシングを排除するものではありません。キャッシュ保持により、マイクロベンチマークではまだ便益があります。ops/usしかし、特定のコールサイトにスレッドローカルキャッシュを追加しようとは思わないでしょう。スレッドローカルを追加することの真のコストを分析するのは難しいためです。多くのスレッドを持つ大規模なアプリケーションではフットプリントがじわじわ大きくなるかもしれませんし、GCによってキャッシュされたオブジェクトが移動された場合にパフォーマンスのペナルティがあるかもしれませんが、これはマイクロベンチマークで適切に捕捉するのは困難です。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。Inside現在40人フォロワーがいます。購読管理このバーを折りたたむ%d人のブロガーが「いいね」をつけました。