对于奇数测试，按位与运算符是否总是比模数更快？答案

【问题标题】：Is it (still) the case that the bitwise AND operator is always faster than modulus for an odd number test?对于奇数测试，按位与运算符是否总是比模数更快？
【发布时间】：2019-02-14 18:47:49
【问题描述】：

我正在阅读一些文章，试图更好地理解位运算符，结果发现了a helpful old blog post from 2012，它指出 - 在对随机正整数 x 的奇数测试中 - 评估 x & 1 比作者的速度快 60%计算机而不是评估x % 2。我在网上其他地方（包括 SO）读到的东西似乎证实了按位运算符更快。

我以前从未在 jsperf 中编写过性能测试，但我有兴趣对此进行测试，看看 Javascript 有多大的不同。在对几种不同的浏览器和设备进行测试后，我惊讶地发现，模数似乎比没有更快。

结果

Chromebook 上的 Chrome

华为 P8 上的 Chrome

Macbook Pro 上的 Chrome

Macbook Pro 上的 Firefox

Macbook Pro 上的 Safari

Macbook Air 上的 Safari

我对每个测试运行了几次以检查结果是否一致。 FF 和 Chrome 有相当一致的赢家，尽管 Safari 确实有更多的摇摆不定。

由于我根本没有性能测试方面的经验，我是否以某种方式编写了严重错误的测试？如果不是，那么现代设备和浏览器是否会以某种方式导致模运算符的性能优于按位与（或性能差异可忽略不计）？这甚至是基准测试的适当方法吗？

或者还有其他我不明白的事情发生吗？（很可能！）

【问题讨论】：

这闻起来是Premature Optimisation
我投票结束这个问题作为题外话，因为有 3 个场景 & 更快，3 个场景更慢，所以前提“& 总是更快”显然是非常错误的。
查看最受好评的 SO Q&A stackoverflow.com/questions/11227809/… 关于分支预测错误，并尝试在没有 ?:/if 条件语句的情况下进行测试。按位整数运算符可以独立处理位，并且总是比位依赖于其他位的结果的浮点运算更快。
顺便说一下number % 2 == 1 不正确（仅适用于非负数）
@PeterB - 谢谢你的评论。在问这个问题之前，我确实考虑了你的逻辑。我仍然认为值得一问的原因是，正如我所说，我从未使用过 jsperf（或任何类似的工具）。因此，我假设我的测试过程中的错误 - 从而使结果无效 - 就像假设本身被证明为真或假一样可能。这也是我添加“性能测试”标签的原因（可能不正确）。

标签： javascript performance performance-testing bitwise-operators logical-operators

【解决方案1】：

我想你已经回答了你自己的问题。总是这样吗？显然不是。与 JavaScript 的许多其他事情一样，结果在很大程度上取决于浏览器，因为每个浏览器都有自己的引擎或实现。

【讨论】：

感谢您的回答。我想知道是否有解释是代码将在用户的浏览器中运行，但我（错误地）假设测试工具运行不操纵 DOM 的纯 Javascript，它会在某处的服务器上运行代码。