欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos
本篇概览
-《Go语言基准测试(benchmark)三部曲》已近尾声,经历了《基础篇》和《内存篇》的实战演练,相信您已熟练掌握了基准测试的常规操作以及各种参数的用法,现在可以学习一些进阶版的技能了,在面对复杂一些的场景也能高效完成基准测试,另外还有几个坑也要提前了解,避免以后掉进去
Go语言基准测试(benchmark)三部曲完整链接
- 基础篇
- 内存篇
- 提高篇
ResetTimer
- 有时候,在基准测试前会有些准备工作,这些准备工作的耗时会影响基准测试的结果,举例如下,BenchmarkFib是常规的基准测试,而BenchmarkFibWithPrepare多了八百毫秒的准备时间
func BenchmarkFib(b *testing.B) {
for n := 0; n < b.N; n {
fib(30)
}
}
// BenchmarkFibWithPrepare 进入正式测试前需要耗时做准备工作的case
func BenchmarkFibWithPrepare(b *testing.B) {
// 假设这里有个耗时800毫秒的初始化操作
<-time.After(800 * time.Millisecond)
// 这下面才是咱们真正想做基准测试的代码
for n := 0; n < b.N; n {
fib(30)
}
}
- 同时执行上述两个基准测试,命令和结果如下,可见因为准备工作的耗时,BenchmarkFibWithPrepare方法的测试结果远不及BenchmarkFib,这与事实是不符合的,因为BenchmarkFibWithPrepare方法的测试目标没有变化,但是因为自身的准备工作导致测试结果出现较大偏差
go test -bench='BenchmarkFib|BenchmarkFibWithPrepare' benchmark-demo
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkFib-8 325 3637442 ns/op
BenchmarkFibWithPrepare-8 50 20173566 ns/op
PASS
ok benchmark-demo 14.871s
- 解决上述问题的思路是不要将准备工作的耗时算入基准测试,实现起来很简简,如下图黄色箭头所示,b.ResetTimer()重置了计时器,前面的耗时都与基准测试无关
- 再做一次基准测试,结果如下,可见800毫秒带来的偏差已被去除
go test -bench='BenchmarkFib|BenchmarkFibWithPrepare' benchmark-demo
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkFib-8 325 3616239 ns/op
BenchmarkFibWithPrepare-8 316 3729323 ns/op
PASS
ok benchmark-demo 5.628s
StopTimer & StartTimer
- 前面通过ResetTimer消除了基准测试前的多余耗时,但是如果多余的耗时出现在基准测试过程中呢?代码如下所示,fib是本次测试的目标,如果每次fib结束后都要做一些耗时的清理工作(这里用10毫秒延时来模仿),才能再次fib,那又该如何消除这10毫秒对基准测试的影响呢?
func BenchmarkFibWithClean(b *testing.B) {
// 这下面才是咱们真正想做基准测试的代码
for n := 0; n < b.N; n {
fib(30)
// 假设这里有个耗时100毫秒的清理操作
<-time.After(10 * time.Millisecond)
}
}
- 先来看看每次fib之后的10毫秒是否会影响基准测试,执行测试的命令和测试结果如下,可见,和没有任何耗时的BenchmarkFib方法相比,BenchmarkFibWithClean的测试结果与fib的真实性能相去甚远
go test -bench='BenchmarkFib$|BenchmarkFibWithClean' benchmark-demo
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkFib-8 322 3610100 ns/op
BenchmarkFibWithClean-8 81 16139196 ns/op
PASS
ok benchmark-demo 3.002s
- 对于这种每次调用fib之前或者之后都会出现的额外耗时操作,可以用b.StartTimer()和b.StopTimer()的组合来消除掉,简单的说就是StartTimer会开启基准测试的计时,StopTimer会暂停计时,具体的使用方法如下
// BenchmarkFibWithClean 假设每次执行完fib方法后,都要做一次清理操作
func BenchmarkFibWithClean(b *testing.B) {
// 这下面才是咱们真正想做基准测试的代码
for n := 0; n < b.N; n {
// 继续记录耗时
b.StartTimer()
fib(30)
// 停止记录耗时
b.StopTimer()
// 假设这里有个耗时100毫秒的清理操作
<-time.After(10 * time.Millisecond)
}
}
- 再次测试,结果如下,去除了多余耗时的基准测试结果,从之前16139196ns恢复到7448678ns,然而,和原始的没有任何处理的BenchmarkFib结果相比依然有一倍左右的差距,看来StartTimer和StopTimer本身也会带来耗时,而且在纳秒级别的测试中会显得非常明显
go test -bench='BenchmarkFib$|BenchmarkFibWithClean' benchmark-demo
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkFib-8 325 3631020 ns/op
BenchmarkFibWithClean-8 241 7448678 ns/op
PASS
ok benchmark-demo 7.751s
危险用法,提前避开
- 现在咱们对benchmark的了解已经比较全面了,可以覆盖大多数单元测试场景,下面有两个反面教材,希望咱们将来都能提前避免类似错误
- 这两个反面教材比较类似:对b.N的错误使用
- 第一个错误用法如下所示,在执行b.N次循环的时候,将当前是第几次作为入参传入了被测试的方法fib
// BenchmarkFibWrongA 演示了错误的基准测试代码,这样的测试可能无法结束
func BenchmarkFibWrongA(b *testing.B) {
for n := 0; n < b.N; n {
fib(n)
}
}
- 上述代码在基准测试的时候可能永远不会结束,这是因为b.N的值并不固定,可能超出了fib方法的设计范围,这样就导致出现意料之外的结果(本意是性能测试,fib的入参应该是设计范围内的),实际运行效果如下,红色箭头指向的状态一直在等待中,只能强行关闭了
- 第二种反面教材也类似,不过更简单,直接拿b.N作为入参,只调用一次fib方法,代码如下所示
func BenchmarkFibWrongB(b *testing.B) {
fib(b.N)
}
- 和前面的BenchmarkFibWrongA比,fib的执行次数似乎少了,但是请注意:b.N到底是多少呢?是否在fib方法的设计范围内?依旧没有明确答案,因此,代码也有可能永远不会结束
- 以本例中的fib为例,实际功能是斐波那契数列,我这边入参等于50的时候,fib方法的耗时是54秒,所以,如果b.N的值再大一些,例如等于100的时候,fib方法就要计算很久了,而计算较大值并不是我们做基准测试的意图
- 至此,Go语言基准测试(benchmark)三部曲就全部完成了,相信此刻的您对除了信心满满,还有就是迫不及待的想去写上一段benchmark代码,看看自己的方法函数究竟性能如何吧
- 希望这三篇文章能给您带来一些参考,golang学习路上,欣宸一路相伴