3

针对大型数组的迭代,for range真的比经典for loop慢吗?

 2 years ago
source link: https://tonybai.com/2022/03/19/for-range-vs-classic-for-loop-when-iterating-large-array/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

针对大型数组的迭代,for range真的比经典for loop慢吗?

本文永久链接 – https://tonybai.com/2022/03/19/for-range-vs-classic-for-loop-when-iterating-large-array

Go语言推崇“一件事情仅有一个作法”!比如:Go仅保留一类循环控制语句,那就是经典版的for loop

for i := 0; i < 100; i++ {
    ... ...
}

而像C语言支持的while、do…while等循环控制语句都被排除在Go简洁的语法之外。但为了方便Go开发者对复合数据类型的迭代,比如:数组、切片、channel以及map等,Go提供了一个变种for range loop,甚至对于map、channel进行遍历,仅能使用for range loop,经典版for loop根本不支持。

不过for range 带来了方便的同时,也给Go初学者带来了一些烦恼,比如:for range迭代复合类型变量时就有一些常见的且十分容易掉入的“坑”,这些“坑”我在《Go语言第一课》中有全面详细的讲解。这里为了给后面的内容做铺垫,只提一个for range的坑,那就是参与循环的是range表达式的副本

我们来看一个专栏中的例子:

func main() {
    var a = [5]int{1, 2, 3, 4, 5}
    var r [5]int

    fmt.Println("original a =", a)

    for i, v := range a {
        if i == 0 {
            a[1] = 12
            a[2] = 13
        }
        r[i] = v
    }

    fmt.Println("after for range loop, r =", r)
    fmt.Println("after for range loop, a =", a)
}

大家来猜猜这段代码会输出什么结果?你是不是觉得这段代码会输出如下结果:

original a = [1 2 3 4 5]
after for range loop, r = [1 12 13 4 5]
after for range loop, a = [1 12 13 4 5]

但实际运行该程序的输出结果却是:

original a = [1 2 3 4 5]
after for range loop, r = [1 2 3 4 5]
after for range loop, a = [1 12 13 4 5]

我们原以为在第一次迭代过程,也就是i = 0时,我们对a的修改 (a[1] =12,a[2] = 13) 会在第二次、第三次迭代中被v取出,但从结果来看,v 取出的依旧是a被修改前的值:2和3。

为什么会是这种情况呢?原因就是参与for range循环的是range表达式的副本。也就是说,在上面这个例子中,真正参与循环的是a的副本,而不是真正的a。

为了方便你理解,我们将上面的例子中的for range循环,用一个等价的伪代码形式重写一下:

for i, v := range a' { //a'是a的一个值拷贝
    if i == 0 {
        a[1] = 12
        a[2] = 13
    }
    r[i] = v
}

现在真相终于揭开了:这个例子中,每次迭代的都是从数组a的值拷贝a’中得到的元素。a’是Go临时分配的连续字节序列,与a完全不是一块内存区域。因此无论a被如何修改,它参与循环的副本a’依旧保持原值,因此v从a’中取出的仍旧是a的原值,而不是修改后的值。

好了,问题来了(来自专栏的一位童鞋的留言)!

这位童鞋的核心问题就一个:对于大型数组,由于参与for range的是该数组的拷贝,那么使用for range是不是会比经典for loop更耗资源且性能更差

我们通过benchmark例子来验证一下:针对大型数组,for range是不是一定就比经典for loop跑得更慢?我们先看第一个例子:

// benchmark1_test.go

package main

import "testing"

func BenchmarkClassicForLoopIntArray(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]int
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr); j++ {
            arr[j] = j
        }
    }
}

func BenchmarkForRangeIntArray(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]int
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j] = j
            _ = v
        }
    }
}

在这个例子中,我们分别用for loop与for range对一个拥有10w个int类型元素的数组进行遍历,我们看看benchmark的结果:

// Go 1.18rc1, MacOS
$go test -bench . benchmark1_test.go
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkClassicForLoopIntArray-8          22080         55124 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeIntArray-8                34808         34433 ns/op           0 B/op          0 allocs/op
PASS
ok      command-line-arguments  3.321s

从输出结果我们看到:for range loop非但未受到large array拷贝操作的影响,其性能居然比for range loop的性能还要好,这显然是在编译器层面(通常是静态单一赋值,即SSA环节)做了优化的结果。

我们关闭优化开关,再运行一下压测:

$go test -c -gcflags '-N -l' .
$./demo.test -test.bench .
goos: darwin
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkClassicForLoopIntArray-8           6248        187773 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeIntArray-8                 4768        246512 ns/op           0 B/op          0 allocs/op
PASS

我们看到:在没有优化的情况下,两种loop的性能都大幅下降,并且for range下降更多,性能显著不如经典for loop。你可以对比一下BenchmarkForRangeIntArray函数在正常优化(go tool compile -S xxx.go)以及关闭优化时(go tool compile -S -N -l)的汇编代码片段,你会发现关闭优化后,汇编代码使用了很多中间变量存储中间结果,而优化后的代码则消除了这些中间状态。

那么接下来你可能会提出这样一个问题:是不是for range迭代任何元素类型的大型数组,其性能都不比经典for loop差呢?我们来看一个对结构体数组遍历的例子:

// benchmark3_test.go
package main

import "testing"

type U5 struct {
    a, b, c, d, e int
}
type U4 struct {
    a, b, c, d int
}
type U3 struct {
    b, c, d int
}
type U2 struct {
    c, d int
}
type U1 struct {
    d int
}

func BenchmarkClassicForLoopLargeStructArrayU5(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U5
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr)-1; j++ {
            arr[j].d = j
        }
    }
}
func BenchmarkClassicForLoopLargeStructArrayU4(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U4
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr)-1; j++ {
            arr[j].d = j
        }
    }
}
func BenchmarkClassicForLoopLargeStructArrayU3(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U3
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr)-1; j++ {
            arr[j].d = j
        }
    }
}
func BenchmarkClassicForLoopLargeStructArrayU2(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U2
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr)-1; j++ {
            arr[j].d = j
        }
    }
}

func BenchmarkClassicForLoopLargeStructArrayU1(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U1
    for i := 0; i < b.N; i++ {
        for j := 0; j < len(arr)-1; j++ {
            arr[j].d = j
        }
    }
}

func BenchmarkForRangeLargeStructArrayU5(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U5
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j].d = j
            _ = v
        }
    }
}
func BenchmarkForRangeLargeStructArrayU4(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U4
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j].d = j
            _ = v
        }
    }
}

func BenchmarkForRangeLargeStructArrayU3(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U3
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j].d = j
            _ = v
        }
    }
}
func BenchmarkForRangeLargeStructArrayU2(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U2
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j].d = j
            _ = v
        }
    }
}
func BenchmarkForRangeLargeStructArrayU1(b *testing.B) {
    b.ReportAllocs()
    var arr [100000]U1
    for i := 0; i < b.N; i++ {
        for j, v := range arr {
            arr[j].d = j
            _ = v
        }
    }
}

在这个例子中,我们定义了5种结构体:U1~U5,它们的不同之处就在于包含的int类型字段的个数不同。我们分别用经典for loop与for range loop对以这些类型为元素的大型数组进行遍历,看看结果如何:

$go test -bench . benchmark3_test.go
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkClassicForLoopLargeStructArrayU5-8        22030         54116 ns/op           0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU4-8        22131         54145 ns/op           0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU3-8        22257         54001 ns/op           0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU2-8        22063         54580 ns/op           0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU1-8        22105         54408 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU5-8               3022        391232 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU4-8               4563        265919 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU3-8               6602        182224 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU2-8              10000        111966 ns/op           0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU1-8              35380         34005 ns/op           0 B/op          0 allocs/op
PASS
ok      command-line-arguments  15.907s

我们看到一个奇怪的现象:无论是哪种结构体类型,经典for loop遍历的性能都是一样的,但for range的遍历性能却会随着结构体字段数量的增多而下降

带着疑惑,我找到了与这个问题有关的一个issue:cmd/compile: optimize large structs,这个issue大致是说对于包含特定数量字段的结构体类型,目前是unSSAable,如果不能SSA,那么就无法通过SSA优化,这也是出现上述benchmark结果的重要原因。

在Go中,几乎所有使用数组的地方都可以用切片替代,笔者还是建议尽量用迭代切片替换对数组的迭代,这样总是可以取得一致且稳定的遍历性能。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2022, bigwhite. 版权所有.

Related posts:


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK