私はsha-256>hmac>pbkdf2暗号アルゴリズムをjavascriptforchromeで最適化しています
http://jsfiddle.net/dtudury/uy3hc/
（コメントの後の// BREADCRUMB） 1行ei = (di + t1) >>> 0;をテストに変更しei = (di + t1);ても、テストは成功しますが、テストの実行時間は1秒未満から7秒にジャンプします。
値を（実際の）intとして格納する必要があることをChromeに伝えていると思います>>> 0...しかし、ある程度の「カーゴカルト」があります。
私の質問は、「これはどこかに文書化されていますか？」です。これがどのように機能するかを確認したり、intについてchromeに伝えるゼロ操作の方法（およびそのようなドキュメントが明らかにするchrome jsコンパイラを予測する他の秘密の方法）を見つけたいと思います。
ありがとう！
一般的な原則は、はい、Chrome / V8は、コードが特定のタイプ（intなど）を一貫して処理しているかどうかを判断し、その場合に最適化しようとすることです。Web上にはJavascriptJIT戦略に関する投稿やプレゼンテーションがたくさんあります...たとえばこことここ。
ただし、この特定のケースでは、バグだと思います。一つには、node.jsでそれを再現することはできません。(di + t1)>>>0さらに、他の一般的なint-castingの「タイプヒント」に置き換えると、Chromeの機能が向上するように見えます(di + t1)|0。~~(di+t1)最後に、Chromeを実行する--js-flags="--trace-opt --trace-deopt --code-comments"と、遅い場合に、_hashWords最適化が解除され、再最適化されることが何十回も行われていることがわかります。これにより、最適化がまったく試行されなかった場合よりもさらに遅くなる可能性があります。（これはCPUのスラッシングに相当すると思います。）興味深いことに、最適化解除の理由はshift-i、コンパイラが数値が整数ではないと想定し続け、整数シフト命令に遭遇するたびに驚かされるように聞こえます。
特定の質問に答えるために、Chromeがコンパイルする正確な方法は文書化されていませんが、パフォーマンスの問題のプロファイリングとデバッグの一般的な原則と方法は文書化されています。これがプロファイリングに関する私のお気に入りの一連の投稿です。これは、Dart-to-JSコンパイラーで作業している人によって書かれています。
編集： Doh、私はそれがunsigned intにキャストしているのに、signedintに>>> 0キャストしていることに気づきました。ChromeのV8がタイプを正しく解決できなかったのはおそらくそのためです。|0~~