我正在为 chrome 优化 javascript 中的 sha-256 > hmac > pbkdf2 加密算法
http://jsfiddle.net/dtudury/uy3hc/
如果我将一行（在注释之后// BREADCRUMB）ei = (di + t1) >>> 0;更改为ei = (di + t1);我的测试仍然通过，但测试运行时从 <1s 跳到 7s
我相信这>>> 0告诉 chrome 它应该将值存储为（实际）int ......但它有一定程度的“货物崇拜”。
我的问题是：“这在任何地方都有记录吗？” 我很想验证它是如何工作的和/或找到一种零操作方式来告诉 chrome 整数（以及任何其他预期此类文档将揭示的 chrome js 编译器的秘密方法）
谢谢你！
一般原则是，是的，Chrome / V8 会尝试确定您的代码是否一直在处理特定类型（如整数），并针对这种情况进行优化。网上有很多关于 Javascript JIT 策略的帖子和演示文稿……例如这里和这里。
但是，在这种特定情况下，我的猜测是这是一个错误。一方面，我无法在 node.js 中重现它。此外，用(di + t1)>>>0其他常见的 int-casting 'type hints'代替似乎(di + t1)|0并~~(di+t1)没有改善 Chrome 中的内容。最后，运行 Chrome--js-flags="--trace-opt --trace-deopt --code-comments"表明，在缓慢的情况下，_hashWords它会被取消优化并重新优化数十次，这可能比根本不尝试优化时更慢。（我想这相当于 CPU 的颠簸。）有趣的是，提供去优化的原因是shift-i，这听起来像是编译器一直假设数字不是整数，然后每次遇到整数移位指令时都会感到惊讶。
为了回答您的具体问题，Chrome 编译的确切方式没有记录，但分析和调试性能问题的一般原则和方法是。这是我最喜欢的关于性能分析的系列文章——它是由从事 Dart-to-JS 编译器工作的人编写的。
编辑： Doh，我刚刚意识到这>>> 0是转换为无符号整数，而|0转换为有符号~~整数。这可能就是 Chrome 的 V8 无法正确解析类型的原因。