循环更多/更少但具有相同数量的 O(1) 操作的算法的性能答案

【问题标题】：Performance of algorithms that loop more/less but with same number of O(1) operations循环更多/更少但具有相同数量的 O(1) 操作的算法的性能
【发布时间】：2018-06-20 02:46:08
【问题描述】：

每当我看到算法优化时，我都会看到很多关于减少循环次数的讨论。很多时候，我看到多个操作被合并到一个循环中，这些操作最初是单独完成的。

最终，执行相同数量的 O(1) 进程。只是一种算法将它们分成多个迭代。从扩展的角度来看，合并操作真的有性能优势吗？

过度简化的示例。我知道这不是一个很好的例子，因为与增加 i 的行为相比，内部时间复杂度操作很低，但你明白我的意思。

let tally1 = 0
let tally2 = 0

for (let i = 0; i < 10; i++) {
  tally1 += 1
}

for (let i = 0; i < 10; i++) {
  tally2 += 1
}

// vs

for (let i = 0; i < 10; i++) {
  tally1 += 1
  tally2 += 1
}

【问题讨论】：

标签： loops optimization time-complexity

【解决方案1】：

很明显，第二个版本的性能会更好，因为构成循环的所有操作只需执行一次。

因此，虽然在循环内执行的操作不会执行得更好或更糟，但整体执行时间会更短。

这是否相关在很大程度上取决于循环内的操作有多昂贵。如果它们很便宜，那么循环的开销就会很明显，并且可能值得优化代码。如果它们很贵，那可能不值得。

除了性能，代码的清晰也是一件好事。因此，如果从性能的角度来看并不重要，您应该选择更易于阅读的代码。

【讨论】：

是的，你的描述是我困惑的根源。我的想法是，可枚举内部的非常复杂的算法不会以有意义的方式受益，从而证明意大利面条代码是合理的。我刚才描述的内容是对您答案的准确评估吗？
我会说是的。

【解决方案2】：

在非常短的循环中，循环构造本身的开销（增量和终止测试）是“显着的”。以至于编译器可能会执行“循环展开”优化，即复制循环体以避免执行中间测试（特别注意处理终止）。

循环合并可以带来类似的加速。

当循环体更复杂时，循环开销变得可以忽略不计，当你合并循环时性能甚至会下降，因为你可能会饱和所需的寄存器数量或降低缓存效率。

对于普通程序来说，这些微优化往往是不值得的。它们更适用于开发具有一般用途的可重用代码，例如 BLAS 例程。

【讨论】：