for & range 性能对比

Golang
380
0
0
2022-04-16
标签   Golang基础

起源

最近在使用 Go 二刷 LeetCode

第一题,两数之和。解题时使用遍历求解,偶然发现使用 forrange的 beats不一致,本着深入研究(啥也不懂)的精神,就想对比下两者的性能如何。

本文参考极客兔兔大佬的原创

探索

既然要对比,那就使用数据说话。

GO test 命令不但可以做单元测试,还支持 bench 进行性能对比。具体操作自行研究,本文就不做深究了。

基本命令:

go test -bench .

首先验证下 int类型的遍历

func genIntSlice(n int) []int {
    rand.Seed(time.Now().UnixNano())
    nums := make([]int, 0, n)for i := 0; i < n; i++ {
        nums = append(nums, rand.Int())}return nums
}

func BenchmarkForIntSlice(b *testing.B) {
    nums := genIntSlice(1024 * 1024)for i := 0; i < b.N; i++ {
        length := len(nums)var tmp intfor k := 0; k < length; k++ {
            tmp = nums[k]}_ = tmp
    }
}

func BenchmarkRangeIntSlice(b *testing.B) {
    nums := genIntSlice(1024 * 1024)for i := 0; i < b.N; i++ {var tmp intfor _, num := range nums {
            tmp = num
        }_ = tmp
    }
}

结果如下:

for & range 性能对比

竟然没有差别。难道结论就是两者没有任何区别吗?我们再来验证下复杂点的类型

深入

我们看下对 struct 的遍历有什么区别

type Item struct {
    id int
    val [4096]byte
}

func BenchmarkForStruct(b *testing.B) {var items [1024]Item
    for i := 0; i < b.N; i++ {
        length := len(items)var tmp intfor k := 0; k < length; k++ {
            tmp = items[k].id
        }_ = tmp
    }
}

func BenchmarkRangeIndexStruct(b *testing.B) {var items [1024]Item
    for i := 0; i < b.N; i++ {var tmp intfor k := range items {
            tmp = items[k].id
        }_ = tmp
    }
}

func BenchmarkRangeStruct(b *testing.B) {var items [1024]Item
    for i := 0; i < b.N; i++ {var tmp intfor _, item := range items {
            tmp = item.id
        }_ = tmp
    }
}

结果如下:

for & range 性能对比

很明显的区别对不对!

  • 仅遍历下标的情况下,for 和 range 的性能几乎是一样的。
  • items 的每一个元素的类型是一个结构体类型 ItemItem 由两个字段构成,一个类型是 int,一个是类型是 [4096]byte,也就是说每个 Item 实例需要申请约 4KB 的内存。
  • 在这个例子中,for 的性能大约是 range (同时遍历下标和值) 的 2000 倍。

继续深入一下,我们如果遍历指针类型呢?

func generateItems(n int) []*Item {
    items := make([]*Item, 0, n)for i := 0; i < n; i++ {
        items = append(items, &Item{id: i})}return items
}

func BenchmarkForPointer(b *testing.B) {
    items := generateItems(1024)for i := 0; i < b.N; i++ {
        length := len(items)var tmp intfor k := 0; k < length; k++ {
            tmp = items[k].id
        }_ = tmp
    }
}

func BenchmarkRangePointer(b *testing.B) {
    items := generateItems(1024)for i := 0; i < b.N; i++ {var tmp intfor _, item := range items {
            tmp = item.id
        }_ = tmp
    }
}

结果如下:

for & range 性能对比

可以看到,几乎没有差别

其实 range在迭代过程中返回的是迭代值的拷贝,这个也可以简单验证下:

persons := []struct{ no int }{{no: 1}, {no: 2}, {no: 3}}
for _, s := range persons {
    s.no += 10
}
for i := 0; i < len(persons); i++ {
    persons[i].no += 100
}
fmt.Println(persons) // [{101} {102} {103}]

最终

range 在迭代过程中返回的是迭代值的拷贝,如果每次迭代的元素的内存占用很低,那么 for 和 range 的性能几乎是一样,例如 []int。但是如果迭代的元素内存占用较高,例如一个包含很多属性的 struct 结构体,那么 for 的性能将显著地高于 range,有时候甚至会有上千倍的性能差异。对于这种场景,建议使用 for,如果使用 range,建议只迭代下标,通过下标访问迭代值,这种使用方式和 for 就没有区别了。如果想使用 range 同时迭代下标和值,则需要将切片/数组的元素改为指针,才能不影响性能。