Go1.0 到 1.22 的性能表现，提高了多少倍？

最新推荐文章于 2024-06-06 16:34:24 发布

煎鱼（EDDYCJY）

最新推荐文章于 2024-06-06 16:34:24 发布

阅读量897

点赞数 27

本文链接：https://blog.csdn.net/eddycjy/article/details/138739713

版权

大家好，我是煎鱼。

五一假期时看到 @Ben Hoyt 大佬分享的文章《Go performance from version 1.0 to 1.22》，分享了他在这么多年来一直坚持不懈的对 Go 进行性能测试的记载。

今天基于此分享给大家，有所调整和精简。

原作者对 Go1.0 到 Go1.22 的所有 Go 版本进行了性能测试，包含了在 Go 1.20 中新增的性能分析引导优化（PGO）的结果。

Go 测试项目用的是 GoAWK^[1] 项目，该项目用 Go 写的 AWK 解释器，支持 CSV。

GoAWK 使用案例如下：

$ go install github.com/benhoyt/goawk@latest

$ goawk 'BEGIN { print "foo", 42 }'
foo 42

$ echo 1 2 3 | goawk '{ print $1 + $3 }'
4

# Or use GoAWK's CSV and @"named-field" support:
$ echo -e 'name,amount\nBob,17.50\nJill,20\n"Boba Fett",100.00' | \
  goawk -i csv -H '{ total += @"amount" } END { print total }'
137.5

性能测试

接下来正式开始进行性能测试，主要是同项目多版本测试的模式。

原作者（下称：我）通过在两个 AWK 程序上运行 GoAWK 来测试这一点，这两个程序代表了使用 AWK 可以做的极端不同情况：I/O 操作与字符串处理，以及数值计算。

countwords（字符串处理任务）

首先是 countwords，这是一个字符串处理任务，它计算输入中单词的频率并打印出带有计数的单词。这是 AWK 脚本的典型应用。

程序输入是某本书的 10 倍串联版本的内容。

以下是部分代码：

{
    for (i=1; i<=NF; i++)
        counts[tolower($i)]++
}

END {
    for (k in counts)
        print k, counts[k]
}

sumloop（循环统计任务）

第二个程序是 sumloop，这是一个紧凑的循环，它多次将循环计数器加到一个变量上。

这个程序并不是 AWK 的典型用法，但它是测试 GoAWK 字节码解释器循环的好方法。

以下是部分代码：

BEGIN {
    for (i=0; i<10000000; i++)
        sum += i+i+i+i+i
}

注：我不得不对 GoAWK 的代码做了一些微调，以便它能在旧版本的 Go 上编译。特别是对于 Go 1.0，因为它没有 bufio.Scanner，而 GoAWK 在很大程度上依赖它。我为 1.0 使用了 Go 1.1 的 bufio.Scanner 实现。

性能测试图表

图表中的计时数字是我在 x86-64 Linux 笔记本电脑上运行三次中的最佳时间（以秒为单位）。蓝线代表 countwords 程序，红线代表 sumloop 程序。

Go 各版本的性能测试结果的图表如下：

请注意，这次 Y 轴是对数的，目的是为了更清晰地看到最近版本中更微妙的改进。

图表中还包括了每个 Go 版本下的 GoAWK 二进制文件大小 —— 那是浅灰色线。

一些要点

1、Go 最大的改进出现在 1.3、1.5、1.7 和 1.12 版本中。在此之后的版本，性能提升变得非常渐进 —— 这意味着所有容易实现的优化早已完成。

2、Go 1.2 性能变差了，countwords 出现了一个奇怪的峰值：它从 1.1 的 7.5 秒增加到 1.2 的 25.5 秒（！），然后下降到 1.3 的 2.8 秒。

我通过分析并注意到 Go 运行时栈操作占据了运行时间的很大一部分，找出了 1.2 异常的原因。

以下是 pprof 输出的前几行：

$ go tool pprof --text ./goawk_1.2 go12.prof
Total: 1830 samples
     332  18.1%  18.1%      332  18.1% runtime.newstack
     296  16.2%  34.3%      296  16.2% runtime.memclr
     281  15.4%  49.7%      281  15.4% runtime.oldstack
     222  12.1%  61.8%      619  33.8% github.com/benhoyt/goawk/interp.(*interp).execute
      91   5.0%  66.8%       91   5.0% runtime.lessstack
      75   4.1%  70.9%      133   7.3% github.com/benhoyt/goawk/interp.(*interp).callBuiltin
      57   3.1%  74.0%       57   3.1% runtime.stackfree
      53   2.9%  76.9%       81   4.4% strings.FieldsFunc
      ...

这几乎可以肯定是由于在 1.3 中修复的堆栈 “热分裂” 问题^[2]所导致的性能下降，因为在该版本 Go 团队将 goroutine 栈的实现从旧的分段模型改为连续模型。

3、PGO 仅将性能提高了几个百分点，使用 Go 1.22，countwords 大约提高了 2%，sumloop 提高了 7%。我使用 PGO 编译了发布的 GoAWK 二进制文件。

4、二进制文件的大小多年来一直保持相对稳定，除了 1.2 版本中的大幅增加。即使启用了 PGO，二进制文件的大小也只有大约 5% 的增加，所以我认为通常这是值得的。