静态分析
静态分析:不执行程序代码,推导程序的行为,分析程序的性质
控制流(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负担