- 为什么要做编译器优化
-
- 用户无感知，重新编译即可获得性能收益
- 通用性优化
- 现状
-
- 采用的优化少
- 编译时间较短，没有进行较复杂的代码分析和优化
- 编译优化的思路
-
- 场景：面向后端长期执行任务
- Tradeoff: 用编译时间换取更高效的机器码
- Beast mode
-
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
- ……
本文由三部分讲述Go性能优化建议， 分别是函数内联、Beast Mode、逃逸分析
First.函数内联 (Inlining)
- 内联：将被调用函数的函数体 (callee) 的副本替换到调用位置 (caller) 上，同时重写代码以反映参数的绑定
- 优点
-
- 消除函数调用开销，例如传递参数、保存寄存器等
- 将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析
- 缺点
-
- 函数体变大，Instructioin cache (icache) 不友好
- 编译生成的Go镜像变大
- 函数内联能多大程度影响性能？—— 使用 micro-benchmark 验证
- 函数内联大多数情况下是正向优化
- 内敛策略
-
- 调用和被调用函数的规模
- …
Second.Beast Mode
- Go 函数内联受到的限制较多
-
- 语言特性，例如 interface, defer 等，限制了函数内联
- 内联策略非常保守
- Beast mode: 调整函数内联的策略，使更多函数被内联
-
- 降低函数调用的开销
- 增加了其他优化的机会：逃逸分析
- 开销
-
- Go 镜像增加 ~10%
- 编译时间增加
Third.逃逸分析
- 逃逸分析：分析代码中指针的动态作用域：指针在何处可以被访问
- 大致思路
-
- 从对象分配处出发，沿着控制流，观察对象的数据流
- 若发现指针 p 在当前作用域 s:
-
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的 goroutine
- 传递给已逃逸的指针指向的对象
- 则指针 p 指向的对象逃逸出 s，反之则没有逃逸出 s
- Beast mode：函数内联拓展了函数边界，更多对象不逃逸
- 优化：未逃逸的对象可以在栈上分配
-
- 对象在栈上分配和回收很快：移动 sp
- 减少在 heap 上的分配，降低 GC 负担
