静态分析
静态分析：不执行程序代码，推导程序的行为，分析程序的性质
控制流（control flow）：程序的执行流程
数据流（data flow）：数据在控制流上的传递
通过分析控制流和数据流，我们可以知道更多关于程序的性质
根据这些性质优化代码
过程内分析和过程间分析
过程内分析：仅在函数内部进行分析
过程间分析：考虑函数调用时参数传递和返回值的数据流和控制流
为什么过程间分析是个问题？
需要通过数据流分析得知i的具体类型，才能知道i.foo()调用的是哪个foo()
根据i的具体类型，产生了新的控制流，i.foo()，分析继续
过程间分析需要同时分析控制流和数据流——联合求解，比较复杂
Go编译器优化
为什么做编译器优化？
用户无感知，重新编译即可获得性能收益
通用性优化
现状：
采用的优化少
编译时间较短，没有进行较复杂的代码分析和优化
编译优化的思路：
场景：面向后端长期执行任务
Tradeoff：用编译时间换取更高效的机器码
Beast mode：
函数内联
逃逸分析
默认栈大小调整
边界检查消除
循环展开
……
函数内联
内联：将被调用函数的函数体的副本替换到调用位置上，同时重写代码以反映参数的绑定
优点：
消除函数调用开销，例如传递参数、保存寄存器等
将过程间分析转化为过程内分析，帮助其他优化，例如逃逸分析
缺点：
函数体变大，instruction cache（icache）不友好
编译生成的Go镜像变大
函数内联在大多数情况下是正向优化
内联策略：
调用和被调函数的规模
函数内联能多大程度影响性能？
使用micro-benchmark验证一下
Beast Mode
Go函数内联受到的限制较多
语言特性，例如interface，defer等，限制了函数内联
内联策略非常保守
Beast mode：调整函数内联的策略，使更多函数被内联
降低函数调用的开销
增加了其他优化的机会：逃逸分析
开销
Go镜像增加~10%
编译时间增加
逃逸分析
逃逸分析：分析代码中指针的动态作用域：指针在何处可以被访问
大致思路：
从对象分配处出发，沿着控制流，观察对象的数据流
若发现指针p在当前作用域s：
作为参数传递给其他函数
传递给全局变量
传递给其他的goroutine
传递给已逃逸的指针指向的对象
则指针p指向的对象逃逸出s，反之则没有逃逸出s
Beast mode：函数内联扩展了函数边界，更多对象不逃逸
优化：未逃逸的对象可以在栈上分配
对象在栈上分配和回收很快：移动sp
减少在heap上的分配，降低GC负担
