为什么执行操作更少的质数计算优化函数反而运行速度更慢？

这是JS引擎底层执行特性和CPU分支预测共同作用的结果，看起来更简洁的新函数实际上产生了更多隐形开销：

• 无用固定开销的差异
  你外层循环已经过滤了所有偶数，传入isPrime的参数除了旧函数第一次处理的2之外，全是奇数，所以模2运算永远不会触发返回false的逻辑。旧函数多出来的if (h === 1) continue是CPU单周期就能完成的整数全等判断，开销远低于模运算（哪怕是优化后的除2移位操作，综合执行成本也高于简单比较），千万次调用累计下来就会出现明显的耗时差。
• CPU分支预测的收益差异
  CPU的分支预测器对固定结果的分支命中率接近100%，几乎没有额外开销：
  • 旧函数的if (h === 1) continue分支每次循环第一次迭代结果永远为真，完全没有预测失效的开销
  • 新函数第一个判断if (h > s) break的结果会随着i的增大不断翻转：当i < h²时结果为真，i ≥ h²时结果为假，每个质数对应的该分支都会翻转一次，每次翻转都会产生十几到几十个CPU周期的预测失效开销，累计下来拖慢了执行速度
• JIT优化的差异
  3.5%左右的性能差也和JS引擎（比如V8）的JIT编译优化有关，旧函数的代码结构刚好更匹配引擎的优化规则，比如对数组遍历、循环展开的优化效果更好。
  你可以做个简单测试验证：把新函数的初始数组改成[1,2]，并在isPrime循环开头加上if (h === 1) continue，两者的性能就会基本持平。

内容的提问来源于stack exchange，提问作者Trubiso