Go1.21中的PGO技术详解

Go中国

于 2023-10-25 09:01:26 发布

阅读量295

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MzA4ODg0NDkzOA==&mid=2247508617&idx=1&sn=994f3e0cf38a2cb41a8e619efeefa0c7&chksm=90211d6ca756947a5013f1da339caf3b725b6b2dc0237ed59c3a25d5918662937b5d98f3f1fd&scene=126&sessionid=0

版权

2023 年初，Go 1.20发布了PGO(Profile-guided optimization)预览版供用户测试。在解决了预览版中的已知限制，并通过社区反馈和贡献进行了额外的改进后，Go 1.21 中的 PGO 支持已准备好用于生产！更多更详细的内容可以参考PGO用户指南（https://go.dev/doc/pgo）。

下面我们将通过一个例子来展示 PGO 如何提高应用程序性能。在此之前，我们先来了解一下“PGO”到底是什么？

当您构建 Go 二进制文件时，Go 编译器会执行优化，尝试生成性能最佳的二进制文件。例如，常量传播可以在编译时计算常量表达式，从而避免运行时成本。逃逸分析避免了本地范围对象的堆分配，从而避免了 GC 开销。内联将简单函数的主体复制到调用者中，通常可以在调用者中进行进一步优化（例如额外的常量传播或更好的逃逸分析）。去虚拟化将对类型可以静态确定的接口值的间接调用转换为对具体方法的直接调用（这通常可以实现调用的内联）。

Go 在各个版本之间不断改进优化，但这样做并不是一件容易的事。有些优化是可调的，但编译器不能在每次优化时都“调至 11”，因为过于激进的优化实际上会损害性能或导致构建时间过长。其他优化要求编译器对函数中的“常见”和“不常见”路径做出判断。编译器必须基于静态启发法做出最佳猜测，因为它无法知道哪些情况在运行时会常见。

或者可以吗？

由于没有关于如何在生产环境中使用代码的明确信息，编译器只能对包的源代码进行操作。但我们确实有一个评估生产行为的工具：分析。如果我们向编译器提供配置文件，它可以做出更明智的决策：更积极地优化最常用的函数，或更准确地选择常见情况。

使用应用程序行为配置文件进行编译器优化称为配置文件引导优化 (PGO)（也称为反馈定向优化 (FDO)）。

举例

让我们构建一个将 Markdown 转换为 HTML 的服务：用户将 Markdown 源文件上传到/render，它返回 HTML 转换。我们可以使用gitlab.com/golang-commonmark/markdown它来轻松实现这一点。

设置

$ go mod init example.com/markdown
$ go get gitlab.com/golang-commonmark/markdown@bf3e522c626a

main.go文件：

package main


import (
    "bytes"
    "io"
    "log"
    "net/http"
    _ "net/http/pprof"


    "gitlab.com/golang-commonmark/markdown"
)


func render(w http.ResponseWriter, r *http.Request) {
    if r.Method != "POST" {
        http.Error(w, "Only POST allowed", http.StatusMethodNotAllowed)
        return
    }


    src, err := io.ReadAll(r.Body)
    if err != nil {
        log.Printf("error reading body: %v", err)
        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        return
    }


    md := markdown.New(
        markdown.XHTMLOutput(true),
        markdown.Typographer(true),
        markdown.Linkify(true),
        markdown.Tables(true),
    )


    var buf bytes.Buffer
    if err := md.Render(&buf, src); err != nil {
        log.Printf("error converting markdown: %v", err)
        http.Error(w, "Malformed markdown", http.StatusBadRequest)
        return
    }


    if _, err := io.Copy(w, &buf); err != nil {
        log.Printf("error writing response: %v", err)
        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        return
    }
}


func main() {
    http.HandleFunc("/render", render)
    log.Printf("Serving on port 8080...")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

构建并运行服务器：

$ go build -o markdown.nopgo.exe
$ ./markdown.nopgo.exe
2023/08/23 03:55:51 Serving on port 8080...

让我们尝试从另一个终端发送一些 Markdown。我们可以使用Go项目中README.md 作为示例文档：

$ curl -o README.md -L "https://raw.githubusercontent.com/golang/go/c16c2c49e2fa98ae551fc6335215fadd62d33542/README.md"
$ curl --data-binary @README.md http://localhost:8080/render
<h1>The Go Programming Language</h1>
<p>Go is an open source programming language that makes it easy to build simple,
reliable, and efficient software.</p>
...

分析

现在我们已经有了一个可以运行的服务，让我们收集一个配置文件并使用 PGO 进行重建，看看是否可以获得更好的性能。

在 main.go中，我们导入了net/http/pprof，它会自动/debug/pprof/profile向服务器添加一个端点以获取 CPU 配置文件。

通常，你希望从生产环境中收集配置文件，以便编译器获得生产中行为的代表性视图。由于此示例没有“生产”环境，因此我创建了一个简单的程序来在收集配置文件时生成负载。获取并启动负载生成器（确保服务器仍在运行！）：

$ go run github.com/prattmic/markdown-pgo/load@latest

当它运行时，从服务器下载配置文件：

$ curl -o cpu.pprof "http://localhost:8080/debug/pprof/profile?seconds=30"

完成后，终止负载生成器和服务器。

使用配置文件

当 Go 工具链在主包目录中找到default.pgo时，它将自动启用 PGO。或者在go build的时候采用-pgo用于 PGO 的配置文件的路径。

我们建议将default.pgo文件提交到你的源码库。将配置文件与源代码一起存储可确保用户只需获取源码库（通过版本控制系统或通过go get）即可自动访问配置文件，并且构建保持可重现。

让我们构建：

$ mv cpu.pprof default.pgo
$ go build -o markdown.withpgo.exe

我们可以使用以下go version命令检查 PGO 是否在构建中启用：

$ go version -m markdown.withpgo.exe
./markdown.withpgo.exe: go1.21.0
...
        build   -pgo=/tmp/pgo121/default.pgo

评估

我们将使用负载生成器的Go 基准版本来评估 PGO 对性能的影响。

首先，我们将对没有 PGO 的服务器进行基准测试。启动该服务器：

$ ./markdown.nopgo.exe

当它运行时，运行几个基准迭代：

$ go get github.com/prattmic/markdown-pgo@latest
$ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > nopgo.txt

完成后，终止原始服务器并使用 PGO 启动该版本：

$ ./markdown.withpgo.exe

当它运行时，运行几个基准迭代：

$ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > withpgo.txt

完成后，让我们比较一下结果：

$ go install golang.org/x/perf/cmd/benchstat@latest
$ benchstat nopgo.txt withpgo.txt
goos: linux
goarch: amd64
pkg: github.com/prattmic/markdown-pgo/load
cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz
        │  nopgo.txt  │            withpgo.txt             │
        │   sec/op    │   sec/op     vs base               │
Load-12   374.5µ ± 1%   360.2µ ± 0%  -3.83% (p=0.000 n=40)

新版本速度提高了约 3.8%！在 Go 1.21 中，启用 PGO 后工作负载的 CPU 使用率通常会提高 2% 到 7%。配置文件包含大量有关应用程序行为的信息，Go 1.21 刚刚开始通过使用这些信息进行一组有限的优化来探索表面。随着编译器的更多部分利用 PGO，未来的版本将继续提高性能。

下一步

在此示例中，收集配置文件后，我们使用原始构建中使用的完全相同的源代码重建了我们的服务器。在现实世界中，总是有持续的改进。因此，我们可以从生产中收集运行上周代码的配置文件，并使用它来构建今天的源代码。那完全没问题！Go 中的 PGO 可以毫无问题地处理源代码的微小更改。当然，随着时间的推移，源代码会越来越漂移，因此偶尔更新配置文件仍然很重要。

有关使用 PGO、最佳实践和注意事项的更多信息，请参阅配置文件引导优化用户指南。如果您对幕后发生的事情感到好奇，请继续阅读！

新引擎的真面目

为了更好地理解是什么让这个应用程序变得更快，让我们深入了解一下性能有何变化。我们将看一下两种不同的 PGO 驱动的优化。

内联

为了观察内联改进，让我们分析这个带有和不带有 PGO 的 Markdown 应用程序。

我将使用一种称为差异分析的技术来对此进行比较，其中我们收集两个配置文件（一个带有 PGO，一个没有）并进行比较。对于差异分析，重要的是两个配置文件代表相同的工作量，而不是相同的时间量，因此我调整了服务以自动收集配置文件，并将负载生成器调整为发送固定数量的请求，然后退出服务。

我对服务所做的更改以及收集的配置文件可以在https://github.com/prattmic/markdown-pgo找到。负载生成器使用时运行-count=300000 -quit。

作为快速一致性检查，让我们看一下处理所有 300k 请求所需的总 CPU 时间：

$ go tool pprof -top cpu.nopgo.pprof | grep "Total samples"
Duration: 116.92s, Total samples = 118.73s (101.55%)
$ go tool pprof -top cpu.withpgo.pprof | grep "Total samples"
Duration: 113.91s, Total samples = 115.03s (100.99%)

CPU 时间从约 118 秒下降到约 115 秒，即约 3%。这与我们的基准结果一致，这是一个好兆头，表明这些配置文件具有代表性。

现在我们可以打开差异配置文件来寻找节省的空间：

$ go tool pprof -diff_base cpu.nopgo.pprof cpu.withpgo.pprof
File: markdown.profile.withpgo.exe
Type: cpu
Time: Aug 28, 2023 at 10:26pm (EDT)
Duration: 230.82s, Total samples = 118.73s (51.44%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top -cum
Showing nodes accounting for -0.10s, 0.084% of 118.73s total
Dropped 268 nodes (cum <= 0.59s)
Showing top 10 nodes out of 668
      flat  flat%   sum%        cum   cum%
    -0.03s 0.025% 0.025%     -2.56s  2.16%  gitlab.com/golang-commonmark/markdown.ruleLinkify
     0.04s 0.034% 0.0084%     -2.19s  1.84%  net/http.(*conn).serve
     0.02s 0.017% 0.025%     -1.82s  1.53%  gitlab.com/golang-commonmark/markdown.(*Markdown).Render
     0.02s 0.017% 0.042%     -1.80s  1.52%  gitlab.com/golang-commonmark/markdown.(*Markdown).Parse
    -0.03s 0.025% 0.017%     -1.71s  1.44%  runtime.mallocgc
    -0.07s 0.059% 0.042%     -1.62s  1.36%  net/http.(*ServeMux).ServeHTTP
     0.04s 0.034% 0.0084%     -1.58s  1.33%  net/http.serverHandler.ServeHTTP
    -0.01s 0.0084% 0.017%     -1.57s  1.32%  main.render
     0.01s 0.0084% 0.0084%     -1.56s  1.31%  net/http.HandlerFunc.ServeHTTP
    -0.09s 0.076% 0.084%     -1.25s  1.05%  runtime.newobject
(pprof) top
Showing nodes accounting for -1.41s, 1.19% of 118.73s total
Dropped 268 nodes (cum <= 0.59s)
Showing top 10 nodes out of 668
      flat  flat%   sum%        cum   cum%
    -0.46s  0.39%  0.39%     -0.91s  0.77%  runtime.scanobject
    -0.40s  0.34%  0.72%     -0.40s  0.34%  runtime.nextFreeFast (inline)
     0.36s   0.3%  0.42%      0.36s   0.3%  gitlab.com/golang-commonmark/markdown.performReplacements
    -0.35s  0.29%  0.72%     -0.37s  0.31%  runtime.writeHeapBits.flush
     0.32s  0.27%  0.45%      0.67s  0.56%  gitlab.com/golang-commonmark/markdown.ruleReplacements
    -0.31s  0.26%  0.71%     -0.29s  0.24%  runtime.writeHeapBits.write
    -0.30s  0.25%  0.96%     -0.37s  0.31%  runtime.deductAssistCredit
     0.29s  0.24%  0.72%      0.10s 0.084%  gitlab.com/golang-commonmark/markdown.ruleText
    -0.29s  0.24%  0.96%     -0.29s  0.24%  runtime.(*mspan).base (inline)
    -0.27s  0.23%  1.19%     -0.42s  0.35%  bytes.(*Buffer).WriteRune

指定时pprof -diff_base，pprof 中显示的值是两个配置文件之间的差异。例如，runtime.scanobject使用 PGO 时比不使用 PGO 时使用的 CPU 时间少 0.46 秒。另一方面，gitlab.com/golang-commonmark/markdown.performReplacements多使用了 0.36 秒的 CPU 时间。在差异分析中，我们通常希望查看绝对值（flat和cum列），因为百分比没有意义。

top -cum显示累积变化的最大差异。也就是说，函数和该函数的所有传递被调用者的 CPU 差异。这通常会显示程序调用图中的最外层框架，例如main或另一个 goroutine 入口点。在这里我们可以看到大部分节省来自ruleLinkify处理 HTTP 请求的部分。

top显示最大的差异仅限于函数本身的变化。这通常会显示程序调用图中的内部框架，其中大部分实际工作都在其中发生。在这里我们可以看到，这些单个的调用节省主要来自runtime。

那么这些是什么呢？让我们查看一下调用堆栈看看它们来自哪里：

(pprof) peek scanobject$
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                            -0.86s 94.51% |   runtime.gcDrain
                                            -0.09s  9.89% |   runtime.gcDrainN
                                             0.04s  4.40% |   runtime.markrootSpans
    -0.46s  0.39%  0.39%     -0.91s  0.77%                | runtime.scanobject
                                            -0.19s 20.88% |   runtime.greyobject
                                            -0.13s 14.29% |   runtime.heapBits.nextFast (inline)
                                            -0.08s  8.79% |   runtime.heapBits.next
                                            -0.08s  8.79% |   runtime.spanOfUnchecked (inline)
                                             0.04s  4.40% |   runtime.heapBitsForAddr
                                            -0.01s  1.10% |   runtime.findObject
----------------------------------------------------------+-------------
(pprof) peek gcDrain$
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                               -1s   100% |   runtime.gcBgMarkWorker.func2
     0.15s  0.13%  0.13%        -1s  0.84%                | runtime.gcDrain
                                            -0.86s 86.00% |   runtime.scanobject
                                            -0.18s 18.00% |   runtime.(*gcWork).balance
                                            -0.11s 11.00% |   runtime.(*gcWork).tryGet
                                             0.09s  9.00% |   runtime.pollWork
                                            -0.03s  3.00% |   runtime.(*gcWork).tryGetFast (inline)
                                            -0.03s  3.00% |   runtime.markroot
                                            -0.02s  2.00% |   runtime.wbBufFlush
                                             0.01s  1.00% |   runtime/internal/atomic.(*Bool).Load (inline)
                                            -0.01s  1.00% |   runtime.gcFlushBgCredit
                                            -0.01s  1.00% |   runtime/internal/atomic.(*Int64).Add (inline)
----------------------------------------------------------+-------------

所以runtime.scanobject最终是来自于runtime.gcBgMarkWorker。Go GC指南告诉我们，这runtime.gcBgMarkWorker是垃圾收集器的一部分，所以runtime.scanobject节省的一定是GC节省的。还有nextFreeFast其他runtime功能呢？

(pprof) peek nextFreeFast$
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                            -0.40s   100% |   runtime.mallocgc (inline)
    -0.40s  0.34%  0.34%     -0.40s  0.34%                | runtime.nextFreeFast
----------------------------------------------------------+-------------
(pprof) peek writeHeapBits
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                            -0.37s   100% |   runtime.heapBitsSetType
                                                 0     0% |   runtime.(*mspan).initHeapBits
    -0.35s  0.29%  0.29%     -0.37s  0.31%                | runtime.writeHeapBits.flush
                                            -0.02s  5.41% |   runtime.arenaIndex (inline)
----------------------------------------------------------+-------------
                                            -0.29s   100% |   runtime.heapBitsSetType
    -0.31s  0.26%  0.56%     -0.29s  0.24%                | runtime.writeHeapBits.write
                                             0.02s  6.90% |   runtime.arenaIndex (inline)
----------------------------------------------------------+-------------
(pprof) peek heapBitsSetType$
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                            -0.82s   100% |   runtime.mallocgc
    -0.12s   0.1%   0.1%     -0.82s  0.69%                | runtime.heapBitsSetType
                                            -0.37s 45.12% |   runtime.writeHeapBits.flush
                                            -0.29s 35.37% |   runtime.writeHeapBits.write
                                            -0.03s  3.66% |   runtime.readUintptr (inline)
                                            -0.01s  1.22% |   runtime.writeHeapBitsForAddr (inline)
----------------------------------------------------------+-------------
(pprof) peek deductAssistCredit$
Showing nodes accounting for -3.72s, 3.13% of 118.73s total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                            -0.37s   100% |   runtime.mallocgc
    -0.30s  0.25%  0.25%     -0.37s  0.31%                | runtime.deductAssistCredit
                                            -0.07s 18.92% |   runtime.gcAssistAlloc
----------------------------------------------------------+-------------

看起来nextFreeFast和其他前 10 名中的一些优化最终来自runtime.mallocgc，GC 指南告诉我们这些优化来自于内存分配器。

GC 和分配器成本的降低意味着我们总体分配的数量更少。让我们看一下堆配置文件了解更多信息：

$ go tool pprof -sample_index=alloc_objects -diff_base heap.nopgo.pprof heap.withpgo.pprof
File: markdown.profile.withpgo.exe
Type: alloc_objects
Time: Aug 28, 2023 at 10:28pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for -12044903, 8.29% of 145309950 total
Dropped 60 nodes (cum <= 726549)
Showing top 10 nodes out of 58
      flat  flat%   sum%        cum   cum%
  -4974135  3.42%  3.42%   -4974135  3.42%  gitlab.com/golang-commonmark/mdurl.Parse
  -4249044  2.92%  6.35%   -4249044  2.92%  gitlab.com/golang-commonmark/mdurl.(*URL).String
   -901135  0.62%  6.97%    -977596  0.67%  gitlab.com/golang-commonmark/puny.mapLabels
   -653998  0.45%  7.42%    -482491  0.33%  gitlab.com/golang-commonmark/markdown.(*StateInline).PushPending
   -557073  0.38%  7.80%    -557073  0.38%  gitlab.com/golang-commonmark/linkify.Links
   -557073  0.38%  8.18%    -557073  0.38%  strings.genSplit
   -436919   0.3%  8.48%    -232152  0.16%  gitlab.com/golang-commonmark/markdown.(*StateBlock).Lines
   -408617  0.28%  8.77%    -408617  0.28%  net/textproto.readMIMEHeader
    401432  0.28%  8.49%     499610  0.34%  bytes.(*Buffer).grow
    291659   0.2%  8.29%     291659   0.2%  bytes.(*Buffer).String (inline)

该-sample_index=alloc_objects选项向我们显示分配的数量，无论大小如何。这很有用，因为我们正在调查 CPU 使用率的下降，而这往往与分配数量而不是大小相关。这里有相当多的减少，但让我们关注最大的减少是，mdurl.Parse。

作为参考，让我们看看没有 PGO 的情况下该函数的总分配计数：

$ go tool pprof -sample_index=alloc_objects -top heap.nopgo.pprof | grep mdurl.Parse
   4974135  3.42% 68.60%    4974135  3.42%  gitlab.com/golang-commonmark/mdurl.Parse

之前的总计数是 4974135，这意味着mdurl.Parse已经消除了 100% 的分配！

回到差异概况，让我们收集更多背景信息：

(pprof) peek mdurl.Parse
Showing nodes accounting for -12257184, 8.44% of 145309950 total
----------------------------------------------------------+-------------
      flat  flat%   sum%        cum   cum%   calls calls% + context
----------------------------------------------------------+-------------
                                          -2956806 59.44% |   gitlab.com/golang-commonmark/markdown.normalizeLink
                                          -2017329 40.56% |   gitlab.com/golang-commonmark/markdown.normalizeLinkText
  -4974135  3.42%  3.42%   -4974135  3.42%                | gitlab.com/golang-commonmark/mdurl.Parse
----------------------------------------------------------+-------------

对mdurl.Parse的调用来自markdown.normalizeLink和markdown.normalizeLinkText

(pprof) list mdurl.Parse
Total: 145309950
ROUTINE ======================== gitlab.com/golang-commonmark/mdurl.Parse in /usr/local/google/home/mpratt/go/pkg/mod/gitlab.com/golang-commonmark/mdurl@v0.0.0-20191124015652-932350d1cb84/parse
.go
  -4974135   -4974135 (flat, cum)  3.42% of Total
         .          .     60:func Parse(rawurl string) (*URL, error) {
         .          .     61:   n, err := findScheme(rawurl)
         .          .     62:   if err != nil {
         .          .     63:           return nil, err
         .          .     64:   }
         .          .     65:
  -4974135   -4974135     66:   var url URL
         .          .     67:   rest := rawurl
         .          .     68:   hostless := false
         .          .     69:   if n > 0 {
         .          .     70:           url.RawScheme = rest[:n]
         .          .     71:           url.Scheme, rest = strings.ToLower(rest[:n]), rest[n+1:]

这些函数和调用者的完整源代码可以在以下位置找到：

mdurl.Parse
markdown.normalizeLink
markdown.normalizeLinkText

那么这里发生了什么？在非 PGO 构建中，mdurl.Parse被认为太大而没有资格进行内联。然而，因为我们的 PGO 配置文件表明对此函数的调用很热，所以编译器确实内联了它们。我们可以从配置文件中的“(inline)”注释中看到这一点：

$ go tool pprof -top cpu.nopgo.pprof | grep mdurl.Parse
     0.36s   0.3% 63.76%      2.75s  2.32%  gitlab.com/golang-commonmark/mdurl.Parse
$ go tool pprof -top cpu.withpgo.pprof | grep mdurl.Parse
     0.55s  0.48% 58.12%      2.03s  1.76%  gitlab.com/golang-commonmark/mdurl.Parse (inline)

mdurl.Parse在第 66 行 ( var url URL) 上创建 URL作为局部变量，然后在第 145 行 ( return &url, nil) 上返回指向该变量的指针。通常，这需要在堆上分配变量，因为对它的引用超出了函数返回的范围。但是，一旦mdurl.Parse内联到markdown.normalizeLink，编译器就可以观察到该变量没有转义normalizeLink，这允许编译器在堆栈上分配它。 markdown.normalizeLinkText类似于markdown.normalizeLink.

优化文件中显示的第二大减少是mdurl.(*URL).String消除内联后逃逸的类似情况。

在这些情况下，我们通过减少堆分配来提高性能。一般来说，PGO 和编译器优化的部分功能在于，对分配的影响根本不是编译器 PGO 实现的一部分。PGO 所做的唯一更改是允许内联这些热函数调用。对逃逸分析和堆分配的所有影响都是适用于任何构建的标准优化。改进的转义行为是内联的一个很大的下游效果，但它不是唯一的效果。许多优化可以利用内联。例如，当某些输入是常量时，常量传播可能能够在内联后简化函数中的代码。

去虚拟化

除了我们在上面的示例中看到的 inling 之外，PGO 还可以驱动接口调用的条件去虚拟化。

在讨论 PGO 驱动的去虚拟化之前，让我们先退后一步，从总体上定义“去虚拟化”。假设您的代码如下所示：

f, _ := os.Open("foo.txt")
var r io.Reader = f
r.Read(b)

这里我们调用了io.Reader接口方法Read。由于接口可以有多个实现，因此编译器会生成间接函数调用，这意味着它会在运行时从接口值中的类型查找要调用的正确方法。与直接调用相比，间接调用具有较小的额外运行时成本，但更重要的是它们排除了一些编译器优化。例如，编译器无法对间接调用执行转义分析，因为它不知道具体的方法实现。

但在上面的例子中，我们确实知道具体的方法实现。它一定是os.(*File).Read，因为*os.File它是唯一可以分配给r 的类型。在这种情况下，编译器将执行去虚拟化，用io.Reader.Read直接调用替换为间接调用os.(*File).Read，从而允许其他优化。

（您可能会想“代码是无用的，为什么有人会那样写？”这是一个很好的观点，但请注意，像上面这样的代码可能是内联的结果。假设被传递到一个带有参数的函数f中io.Reader。一旦函数被内联，现在它就io.Reader变得具体了。）

PGO 驱动的去虚拟化将此概念扩展到具体类型不是静态已知的情况，但分析可以显示，例如，大多数时间io.Reader.Read调用目标。os.(*File).Read在这种情况下，PGO 可以替换r.Read(b)为：

if f, ok := r.(*os.File); ok {
    f.Read(b)
} else {
    r.Read(b)
}

也就是说，我们为最有可能出现的具体类型添加运行时检查，如果是这样，则使用具体调用，否则回退到标准间接调用。这里的优点是公共路径（使用*os.File）可以内联并应用额外的优化，但我们仍然保留后备路径，因为配置文件并不能保证始终如此。

在我们对 Markdown 服务的分析中，我们没有看到 PGO 驱动的去虚拟化，但我们也只关注了受影响最大的区域。PGO（以及大多数编译器优化）通常会在许多不同地方进行非常小的改进的总和中产生大的优化，因此可能发生的事情不仅仅是我们所看到的。

内联和去虚拟化是 Go 1.21 中提供的两种 PGO 驱动的优化，但正如我们所见，这些通常会解锁额外的优化。此外，Go的未来版本将继续通过额外的优化来改进PGO。

Go中国

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Go1.21中的PGO技术详解

2023 年初，Go 1.20发布了PGO(Profile-guided optimization)预览版供用户测试。在解决了预览版中的已知限制，并通过社区反馈和贡献进行了额外的改进后，Go 1.21 中的 PGO 支持已准备好用于生产！更多更详细的内容可以参考PGO用户指南（https://go.dev/doc/pgo）。下面我们将通过一个例子来展示 PGO 如何提高应用程序性能。在此之前，我们...
复制链接

扫一扫