这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
Go 编译器的历史
Go 编译器在2007年左右开始作为 Plan9 编译器工具链的一个分支。当时的编译器与 Aho 和 Ullman 的 Dragon Book 非常相似。
2015年，当时的 Go 1.5 编译器 从 C 机械地翻译成 Go。
一年后，Go 1.7 引入了一个基于 SSA 技术的 新编译器后端 ，取代了之前的 Plan 9风格的代码。这个新的后端为泛型和体系结构特定的优化提供了许多可能。
内联
在 Go 中，函数调用有固定的开销；栈和抢占检查。
硬件分支预测器改善了其中的一些功能，但就功能大小和时钟周期而言，这仍然是一个成本。
内联是避免这些成本的经典优化方法。
内联只对叶子函数有效，叶子函数是不调用其他函数的。这样做的理由是:
- 如果你的函数做了很多工作，那么前序开销可以忽略不计。
- 另一方面，小函数为相对较少的有用工作付出固定的开销。这些是内联目标的功能，因为它们最受益。
还有一个原因就是严重的内联会使得堆栈信息更加难以跟踪。
func Max(a, b int) int {
if a > b {
return a
}
return b
}
func F() {
const a, b = 100, 20
if Max(a, b) == b {
panic(b)
}
}
我们再次使用 -gcflags = -m 标识来查看编译器优化决策。
% go build -gcflags=-m examples/max/max.go
# command-line-arguments
examples/max/max.go:3:6: can inline Max
examples/max/max.go:12:8: inlining call to Max
编译器打印了两行信息：
- 首先第3行，
Max的声明告诉我们它可以内联 - 其次告诉我们，
Max的主体已经内联到第12行调用者中。
逃逸分析
为了说明逃逸分析，首先让我们来回忆一下在 Go spec 中没有提到堆和栈，它只提到 Go 语言是有垃圾回收的，但也没有说明如何是如何实现的。
一个遵循 Go spec 的 Go 实现可以将每个分配操作都在堆上执行。这会给垃圾回收器带来很大压力，但这样做是绝对错误的 -- 多年来，gccgo对逃逸分析的支持非常有限，所以才导致这样做被认为是有效的。
然而，goroutine 的栈是作为存储局部变量的廉价场所而存在；没有必要在栈上执行垃圾回收。因此，在栈上分配内存也是更加安全和有效的。
在一些语言中，如C和C++，在栈还是堆上分配内存由程序员手动决定——堆分配使用malloc 和free，而栈分配通过alloca。错误地使用这种机制会是导致内存错误的常见原因。
在 Go 中，如果一个值超过了函数调用的生命周期，编译器会自动将之移动到堆中。我们管这种现象叫：该值逃逸到了堆。
type Foo struct {
a, b, c, d int
}
func NewFoo() *Foo {
return &Foo{a: 3, b: 1, c: 4, d: 7}
}
在这个例子中，NewFoo 函数中分配的 Foo 将被移动到堆中，因此在 NewFoo 返回后 Foo 仍然有效。
这是从早期的 Go 就开始有的。与其说它是一种优化，不如说它是一种自动正确性特性。无法在 Go 中返回栈上分配的变量的地址。
同时编译器也可以做相反的事情；它可以找到堆上要分配的东西，并将它们移动到栈上。
让我们来看下面的例子：
// Sum 函数返回 0-100 的整数之和
func Sum() int {
const count = 100
numbers := make([]int, count)
for i := range numbers {
numbers[i] = i + 1
}
var sum int
for _, i := range numbers {
sum += i
}
return sum
}
Sum 将 0-100 的 ints型数字相加并返回结果。
因为 numbers 切片仅在 Sum函数内部使用，编译器将在栈上存储这100个整数而不是堆。也没有必要对 numbers进行垃圾回收，因为它会在 Sum 返回时自动释放。
调查逃逸分析
证明它！
要打印编译器关于逃逸分析的决策，请使用-m标志。
% go build -gcflags=-m examples/esc/sum.go
# command-line-arguments
examples/esc/sum.go:8:17: Sum make([]int, count) does not escape
examples/esc/sum.go:22:13: answer escapes to heap
examples/esc/sum.go:22:13: main ... argument does not escape
第8行显示编译器已正确推断 make([]int, 100)的结果不会逃逸到堆。
第22行显示answer逃逸到堆的原因是fmt.Println是一个可变函数。 可变参数函数的参数被装入一个切片，在本例中为[]interface{}，所以会将answer赋值为接口值，因为它是通过调用fmt.Println引用的。 从 Go 1.6（可能是）开始，垃圾收集器需要通过接口传递的所有值都是指针，编译器看到的是这样的：
var answer = Sum()
fmt.Println([]interface{&answer}...)
我们可以使用标识 -gcflags="-m -m" 来确定这一点。会返回：
examples/esc/sum.go:22:13: answer escapes to heap
examples/esc/sum.go:22:13: from ... argument (arg to ...) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: from *(... argument) (indirection) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: from ... argument (passed to call[argument content escapes]) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: main ... argument does not escape
总之，不要担心第22行，这对我们的讨论并不重要。
Beast Mode
1.Go函数内联受到的限制较多
（1）语言特性，例如interface, defer等，限制了函数内联
（2）内联策略非常保守
2.Beast mode:调整函数内联的策略，使更多函数被内联
（1）降低函数调用的开销
（2）增加了其他优化的机会:逃逸分析
3.开销
（1）Go镜像增加~10%
（2）编译时间增加
