Go 编译器优化
《从.go 文本文件到可执行文件》一文中，我们简单描述了 Go 编译器的工作流程。本文将继续深入其中的一些代码优化的工作。
死代码消除
死代码消除（ dead code elimination, 缩写 DCE ）是用来移除对程序执行结果没有任何影响的代码，以此 减少程序的体积大小 ，并且还可以避免程序在执行过程中进行一些不必要的运算行为，从而 减少执行时间 。
需要注意的是，除了不会执行到的代码（ unreachable code ），一些只会影响到无关程序执行结果的变量（ dead variables ），也属于死码（ dead code ）的范畴。
简单示例：
package main
func main() {
const a, b = 200, 100
var max int
if a > b {
max = a
} else {
max = b
}
if max == b {
panic(b)
}
}
对于常量 a 和 b ，编译器在编译时可以判断出 a 永远是大于 b 的，即 a > b 永远为 true ，也就是说 else {} 分支属于 unreachable code 将永远不会被执行，所以编译器会进行第一次优化：分支消除
package main
func main() {
const a, b = 200, 100
const max = a
if max == b {
panic(b)
}
}
由于 max 变量后续没有再被引用，所以 max 实际也是一个常量。相同道理，max == b 永远为 false ，编译器会进行第二次分支消除优化：
package main
func main() {
const a, b = 200, 100
const max = a
}
对于剩下的常量则明显属于 dead variables ，再次优化：
package main
func main() {
}
我们可以查看最初程序的 SSA 生成过程来验证：
$ GOSSAFUNC=main go build main.go
查看生成的 ssa.html ：
可以看到，main 函数内的所有逻辑确实都被编译器优化掉了。
函数内联
如果程序中存在大量的小函数的调用，函数内联（function call inlining）就会直接用函数体替换掉函数调用来 减少因为函数调用而造成的额外上下文切换开销 。
简单示例：
package main
func main() {
n := 1
for i := 0; i < 10; i++ {
n = double(n)
}
println(n)
}
func double(n int) int {
return 2 * n
}
对于上面的代码，编译器内联优化后会变成：
package main
func main() {
n := 1
for i := 0; i < 10; i++ {
n = 2 * n
}
println(n)
}
Go 编译器会计算函数内联所花费的成本，只有满足相关策略时才会进行内联优化，最简单的当函数内有 go 、defer 、select 等关键字时就不会发生内联，具体的策略可以直接查看源码：
使用 go tool compile -m=2 main.go 或 go build -gcflags="-m -m" main.go 可以输出内联优化的相关信息（ -m 的数量越多输出结果越详细）
$ go tool compile -m=2 main.go
main.go:11:6: can inline double with cost 4 as: func(int) int { return 2 * n }
main.go:3:6: can inline main with cost 28 as: func() { n := 1; for loop; println(n) }
main.go:6:13: inlining call to double
或者也可以输出汇编代码查看是否有进行 double 函数的调用，这里显然是没有的：
$ go tool compile -S main.go | grep CALL.*double
如果我们不想一个函数被内联，可以直接在其函数定义时加一个 //go:noinline 注释：
//go:noinline
func double(n int) int {
return 2 * n
}
同样可以进行验证：
$ go tool compile -S main.go | grep CALL.*double
0x0025 00037 (main.go:6) CALL "".double(SB)
$ go tool compile -m=2 main.go
main.go:12:6: cannot inline double: marked go:noinline
main.go:3:6: cannot inline main: function too complex: cost 81 exceeds budget 80
可以看到此时还输出了函数无法内联的原因。
如果希望所有函数都不执行内联操作，可以直接为编译器选项加上 -l 参数，即 go build -gcflags="-l" main.go （如果 -l 数量大于等于 2 ，编译器将会采用更激进的内联策略，但也可能会生成更大的二进制文件）。
正常情况，我们直接使用编译器默认选项即可。
逃逸分析
不同于 C 语言的手动内存管理方式（通过 malloc 分配堆内存对象， free 手动释放），带有 GC 机制的 Go 语言在编译阶段会进行逃逸分析，自动决定将变量分配到 goroutine 的栈（stack）内存区或者全局的堆（heap）内存区上 。
其中的逃逸规则有很多，最简单的一种是：如果变量超出了函数调用的生命周期，编译器就会将其逃逸到堆上。
简单示例：
package main
func main() {
A()
B()
}
func A() int {
a := 1024
return a
}
func B() *int {
b := 1024
return &b
}
重点关注返回指针类型的 B 函数，通过 go tool compile -l -m=2 main.go 来查看逃逸结果（ -l 是全局禁止函数内联，避免影响逃逸分析）：
$ go tool compile -l -m=2 main.go
main.go:14:2: b escapes to heap:
main.go:14:2: flow: ~r0 = &b:
main.go:14:2: from &b (address-of) at main.go:15:9
main.go:14:2: from return &b (return) at main.go:15:2
main.go:14:2: moved to heap: b
根据结果可以看出 B 函数中分配的变量 b 逃逸到了堆上（moved to heap: b），而对于全程在 A 函数生命周期内的 a 变量则没有发生逃逸（直接在栈上分配了）。
$ go tool compile -S main.go | grep runtime.newobject
0x0020 00032 (main.go:14) CALL runtime.newobject(SB)
rel 33+4 t=7 runtime.newobject+0
从汇编来看，也只有在 main.go:14 （对应源码：b := 1024 ）位置处才调用了 runtime.newobject 函数。
而 runtime.newobject 函数的作用正是执行 malloc 动作 在堆上分配内存 。
在栈上分配内存，将直接由 CPU 提供 push（入栈）和 pop（出栈） 指令支持，但在堆上分配，就需要额外等待 Go GC 负责回收，虽然 Go GC 十分高效，但也不可避免会造成一定的性能损耗。
所以如果想要追求极致性能，我们就要尽量避免一些不必要的堆内存分配。