javascript - chrome javascript 优化深度魔法

Question

我正在为 chrome 优化 sha-256 > hmac > pbkdf2 加密算法

http://jsfiddle.net/dtudury/uy3hc/

如果我更改一行(在注释 //BREADCRUMB 之后)ei = (di + t1) >>> 0; 到 ei = (di + t1); 我的测试仍然通过，但测试运行时间从 <1s 跳到 7s

我相信 >>> 0 告诉 chrome 它应该将值存储为(实际)int...但是它有一定程度的“ cargo 崇拜”。

我的问题是:“这在任何地方都有记录吗？”我很想验证这是如何工作的和/或找到一种零操作方式来告诉 chrome 关于 int 的信息(以及任何其他预测此类文档会揭示的 chrome js 编译器的 secret 方式)

谢谢!

Answer 1

一般原则是，是的，Chrome/V8 会尝试确定您的代码是否始终处理特定类型(如 int)，并针对该情况进行优化。网上有很多关于 Javascript JIT 策略的帖子和演示文稿……例如here和 here .

不过，在这种特定情况下，我的猜测是这是一个错误。首先，我无法在 node.js 中重现它。此外，用 (di + t1)|0 和 ~~ (di+t1) 似乎没有改进 Chrome 中的内容。最后，使用 --js-flags="--trace-opt --trace-deopt --code-comments" 运行 Chrome 显示在缓慢的情况下，_hashWords进行了数十次去优化和重新优化，这可能比根本不尝试优化更慢。 (我想这是 CPU 等同于抖动。)有趣的是，为去优化提供的原因是 shift-i，这听起来像是编译器一直假设数字不是整数，然后感到惊讶每次遇到整数移位指令。

为了回答您的具体问题，Chrome 编译事物的确切方式没有记录，但分析和调试性能问题的一般原则和方法是记录的。 Here's我最喜欢的关于性能分析的系列文章 -- 它是由从事 Dart-to-JS 编译器的人写的。

编辑 Doh，我刚刚意识到 >>> 0 正在转换为 unsigned int，而 |0 和 ~~ 转换为带符号的 int。这可能就是 Chrome 的 V8 无法正确解析类型的原因。