循环中数组条目分配速度缓慢的原因是什么？

哈喽！今天心血来潮给大家带来了《循环中数组条目分配速度缓慢的原因是什么？》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

我发现这个奇怪的基准测试结果似乎表明，如果不在循环中完成，则分配数组元素会更快。希望有人能解释一下。完整的 go 代码如下，基准 benchmarkdirectassignment 的运行速度似乎快了十倍，即使它做的是同样的事情：

package main

import "testing"

func benchmarkloopassignment(b *testing.b) {
  arr := make([]int, 10)
  for n := 0; n < b.n; n++ {
    for i := 0; i < 10; i++ {
      arr[i] = n
    }
  }
}

func benchmarkdirectassignment(b *testing.b) {
  arr := make([]int, 10)
  for n := 0; n < b.n; n++ {
    arr[0] = n
    arr[1] = n
    arr[2] = n
    arr[3] = n
    arr[4] = n
    arr[5] = n
    arr[6] = n
    arr[7] = n
    arr[8] = n
    arr[9] = n
  }
}

$ go test -bench=.
goos: windows
goarch: amd64
BenchmarkLoopAssignment-16              500000000                3.76 ns/op
BenchmarkDirectAssignment-16            2000000000               0.25 ns/op
PASS
ok      _/D_/go_benchmark       3.107s

我在 java 和 c# 中复制了这一点，并得到了相同的结果 - 直接赋值总是更快。有谁知道为什么会发生这种情况？谢谢！

解决方案

在第一个示例中，您有一个循环。每次迭代至少是 1 次跳转 + 修改和检查运行变量。这是您在任务之上的开销。

在第二个示例中，您对作业进行了硬编码。这些命令必须按顺序读取。没有跳转、计数或检查相关开销。

但是值得指出的是，差异几乎不重要：

https://ericlippert.com/2012/12/17/performance-rant/

无论如何，您都不可能将情况 2 用于非常大的列表。至少不是一些自动代码创建的这一面，

第一个示例涉及一些在实际分配完成之前使用 cpu、内存的额外计算。 但对于第二个示例，它是直接赋值，无需更多计算。 正如其他答案提到的那样，对于这个示例案例来说并不重要，但是对于更复杂/大型的数据集，算法如何有效地工作确实很重要。

由于计算相同，上述结果对于其他编程语言也可能相同。

关于复杂性和 big-O 的一些很好的注释，这可能会有所帮助 http://pages.cs.wisc.edu/~vernon/cs367/notes/3.COMPLEXITY.html

以上就是《循环中数组条目分配速度缓慢的原因是什么？》的详细内容，更多关于的资料请关注golang学习网公众号！