两年前，我在 1.2 到 1.18 的所有 Go 版本上比较了 GoAWK 解释器的两个不同基准。
在本文中，我重新运行这些基准测试，添加缺少的 Go 版本（1.0 和 1.1）以及新版本（1.19 到 1.22）。我还包含了 Go 1.20 中添加的配置文件引导优化 (PGO) 的结果。我将引用我原来文章中的一些内容，这样您就不必重新阅读旧文章来理解设置。
用 Go 编写的程序可以通过多种方式变得更快：Go 团队和外部贡献者改进了编译器，并优化了运行时、垃圾收集器和标准库。在这里，我们比较了使用 Go 的每个发布版本（从 1.0 到 1.22）（撰写本文时的最新版本）编译时 GoAWK 的性能。
我通过在两个 AWK 程序上运行 GoAWK 来测试这一点，这两个程序代表了使用 AWK 可以执行的不同极端操作：带有字符串处理的 I/O 和数字运算。
首先，我们有
countwords
，一个字符串处理任务，它计算输入中单词的频率并打印出单词及其计数。这是 AWK 脚本的典型情况。输入是 King James Bible 的 10 倍串联版本（我之前用过它来进行性能比较）。代码如下：
{ for (i=1; i<=NF; i++) counts[tolower($i)]++}
END { for (k in counts) print k, counts[k]}
第二个程序是
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 中使用了
bufio.Scanner
的 Go 1.1 实现。
图表中的计时数字是我的 x86-64 Linux 笔记本电脑上的时间（以秒为单位）（三轮运行中最好的）。蓝线是
countwords
，红线是
sumloop
（顺便说一句，我上次错误地标记了结果）。请注意，这次 Y 轴是对数的，以便更清楚地看到最近版本中更微妙的改进。
图表中还包括每个 Go 版本的 GoAWK 二进制大小 - 即浅灰色线。
我再次使用 Python 脚本来运行它们并测量时间。这是图表（如果您愿意，也可以作为表格）：
最大的改进来自版本 1.3、1.5、1.7 和 1.12。之后，速度会逐渐加快——所有容易实现的目标都早已被采摘了。
这次，Go 1.2 中的
countwords
出现了奇怪的变化：它从 1.1 中的 7.5 秒增加到 1.2 中的 25.5 秒（！），然后在 1.3 中下降到 2.8 秒。这几乎肯定是由堆栈“热分割”问题引起的，该问题在 1.3 中得到了修复，因为 Go 团队将“goroutine 堆栈的实现从旧的‘分段’模型更改为连续模型”。
我通过分析找出了 1.2 异常的原因，并注意到运行时堆栈操作占了运行时间的很大一部分。这是
pprof
输出的前几行：
