参考文章

PGO介绍：
https://andrewwphillips.github.io/blog/pgo.html
生成profile配置文件：
https://andrewwphillips.github.io/blog/flame-graphs.html#generating-cpu-profiles

提案：Go 的配置文件引导优化（PGO）的设计和实现：
https://go.googlesource.com/proposal/+/master/design/55022-pgo-implementation.md

go官方文档使用PGO:
https://go.dev/doc/pgo#:~:text=Collecting%20representative%20profiles%20from%20production

PGO：为你的go程序提效5%：
https://colobu.com/2023/09/13/pgo/

PGO是什么

引入官方的说法：https://go.dev/doc/pgo#merging-profiles
从 Go 1.20 开始，Go 编译器支持配置文件引导优化 (PGO) 以进一步优化构建。
Profile-guided optimization (PGO)。配置文件引导优化 (PGO)，也称为反馈导向优化 (FDO)，是一种编译器优化技术，它将应用程序的代表性运行中的信息（配置文件）反馈回编译器，以供下一次构建应用程序使用。它使用该信息做出更明智的优化决策。例如，编译器可能决定更积极地内联配置文件指示频繁调用的函数。
在Go中，编译器使用CPU pprof配置文件作为输入配置文件，例如来自runtime/pprof或net/http/pprof。
从 Go 1.22 开始，一组代表性 Go 程序的基准测试表明，使用 PGO 进行构建可将性能提高约 2-14%。

自Go 1.20版本引入PGO(profile-guided optimization)后，PGO这种优化技术带来的优化效果就得到了持续的提升：Go 1.20实测性能提升仅为1.05%；Go 1.21版本发布时，官方的数据是2%~7%，而Go 1.21编译器自身在PGO优化过后编译速度提升约6%。
在Go 1.22中，官方给出的数字则是2%~14%，这14%的提升想必是来自Google内部的某个实际案例。

使用PGO的好处

提升性能，降低成本。
在 Google 服务器上运行的大部分代码都是使用 PGO 构建的。当你考虑到（我的估计）所有这些服务器的电费每年必须接近（如果不超过）10 亿美元时，PGO 每年可能至少为 Google 节省数千万美元。所以从经济上来说这是有道理的。

PGO做了什么

热函数内联

什么是内联

所谓内联，指的是编译期间，直接将调用函数的地方替换为函数的实现，它可以减少函数调用的开销以提高程序的性能。

内联的好处

1. 解除函数调用的开销，以空间换时间；
2. 支持编译器更有效地应用其他优化策略。

Go默认的内联策略

1. 函数足够简单，当解析AST时，Go申请了80个节点作为内联的预算。每个节点都会消耗一个预算。函数的开销不能超过这个预算；
2. 不能包含闭包，defer，recover，select；
3. 不能以 go:noinline 或 go:unitptrescapes 开头；
4. 必须有函数体；
5. 其他等复杂要求，详细可见src/cmd/compile/internal/gc/inl.go相关内容。我们可以使用 gcflags 参数来判断能不能内联。

PGO的热函数内联

如果调用次数较多的函数（所谓的热函数）稍微超出内联预算，则可能不会内联它们。
PGO 做了几件事来使内联更加有效。首先，它增加了热点函数的内联预算。
PGO 避免内联 CPU 配置文件显示为冷函数的函数。同样，这减少了不必要的代码膨胀。

去虚拟化调用

通过接口调用方法比直接方法/函数调用慢。CPU配置文件可以显示调用的具体类型是什么，从而在编译的时候，直接优化为具体类型的调用：

type I interface { f() }
...
    var i I
    ...
    i.f()


# PGO优化
    # 热路径
    if a, ok := i.(A); ok {
        a.f() // direct call
    } else {
        i.f()
    }

指令高速缓存

CPU 配置文件允许编译器通过代码查找常用执行路径或热路径。编译器将对函数内的代码块重新排序，并且（稍后在构建过程中）链接器将调整函数的位置，从而确定将它们加载到指令内存中的位置。

PGO有什么缺点

可执行程序变大

由于额外的函数内联，PGO 可能会产生稍大的二进制文件。

构建时间变长

启用 PGO 构建可能会导致包构建时间显着增加。其中最值得注意的部分是 PGO 配置文件适用于二进制文件中的所有包，这意味着首次使用配置文件需要重建依赖关系图中的每个包。这些构建像其他构建一样被缓存，因此使用相同配置文件的后续增量构建不需要完全重建。
例如：https://github.com/golang/go/issues/58102 构建时间可能会增加好几倍，当然go官方团队也在致力于解决这个问题。

PGO怎么使用

典型的工作流程

1. 构建并发布初始二进制文件（不含 PGO）。
2. 从生产中收集配置文件。
3. 当需要发布更新的二进制文件时，从最新源构建并提供生产配置文件。
4. 转到2

收集CPU配置文件

明确不开启PGO的情况下，例如go build -pgo=off，使用pprof进行CPU配置收集，收集结果为default.pgo。建议是收集生产环境的CPU配置文件更为精准，当然如果可以保证测试/仿真环境和生产环境一致的话，在测试/仿真环境收集也是OK的。

生产环境启动PGO

go1.21之后默认开启了PGO,也可以在编译的时候手动设置。
例如:

1. 开启PGO: go build -pgo=auto
2. 设置PGO配置文件路径： go build -pgo=/tmp/foo.pprof

代码改动重新生成CPU配置文件

如果无法评估迭代对于CPU配置文件的影响，建议是发布的时候重新收集CPU配置，参考上面的流程。 go官方建议PGO文件可以提交到版本库里面，方便对比和管理。

PGO的未来

有很多“微观”优化的机会。例如，如果在堆上分配的变量不需要在热路径中转义，则该变量可以在堆栈上分配，并且仅在采用冷路径时才移动到堆。
一件重要的事情（随着泛型的使用越来越多）是称为模板的功能。当在热路径中调用泛型函数时，PGO 可以确定类型参数，并专门为该类型生成代码（甚至可能在热调用站点内联它！）
未来要迭代的方向：https://github.com/golang/go/issues/62463

个人看法

对于GO程序来说，大家认为整体还是比较高效的，只是相对于c和rust来说性能确实有差距，可能达到25%的性能差距，但是GO的易用性和生态弥补了这一缺陷。只是谁又不想让自己的程序快一点，占用资源少一点呢？

对小型项目来说，关注新技术即可，没必要强行上PGO。毕竟有一定的构建成本，且小型项目对性能和成本不敏感。而对于大型项目或者大型互联网公司来说，例如字节，B站这些，别说14%的优化了，2%的优化都值得正确，可能带来的是千万级的成本节省。

QA

Q1 PGO是否可以优化标准包和依赖的包

是的。 Go中的PGO适用于整个程序。所有包都会重新构建，以考虑潜在的配置文件引导优化，包括依赖项中的包。这意味着应用程序使用依赖项的独特方式会影响应用于该依赖项的优化。

Q2 CPU配置文件不当是否会使我的程序比没有 PGO 的速度慢？

不应该。虽然不代表生产行为的配置文件将导致应用程序冷部分的优化，但它不应该使应用程序热部分变慢。如果您遇到 PGO 导致性能比禁用 PGO 更差的程序，请在go.dev/issue/new提交问题。

Q3 怎么保证收集到公正的CPU配置文件

1. 在高峰期，平稳期或者任何时间，都可以收集CPU配置文件
2. 合并收集到的多个配置文件：

$ go tool pprof -proto a.pprof b.pprof > merged.pprof

这种合并实际上是输入中样本的简单求和，无论配置文件的墙持续时间如何。因此，当分析应用程序的小时间片（例如，无限期运行的服务器）时，您可能希望确保所有配置文件具有相同的墙持续时间（即，收集所有配置文件 30 秒）。否则，具有较长墙持续时间的配置文件将在合并的配置文件中过多表示。

Q4 不同运行环境下如何使用PGO

1. 相同的CPU配置文件，可以在linux和windows上的应用程序使用。对于大多数应用程序来说，绝大多数代码是平台无关的，因此这种形式的退化是有限的。
2. 为不同运行环境生成独有的CPU配置。代价就是增加管理负担。

end