Go语言基准测试(benchmark)三部曲之三：提高篇

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

本篇概览

-《Go语言基准测试(benchmark)三部曲》已近尾声，经历了《基础篇》和《内存篇》的实战演练，相信您已熟练掌握了基准测试的常规操作以及各种参数的用法，现在可以学习一些进阶版的技能了，在面对复杂一些的场景也能高效完成基准测试，另外还有几个坑也要提前了解，避免以后掉进去

ResetTimer

有时候，在基准测试前会有些准备工作，这些准备工作的耗时会影响基准测试的结果，举例如下，BenchmarkFib是常规的基准测试，而BenchmarkFibWithPrepare多了八百毫秒的准备时间

go 复制代码

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方法的测试目标没有变化，但是因为自身的准备工作导致测试结果出现较大偏差

shell 复制代码

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毫秒带来的偏差已被去除

shell 复制代码

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毫秒对基准测试的影响呢？

go 复制代码

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的真实性能相去甚远

shell 复制代码

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会暂停计时，具体的使用方法如下

go 复制代码

// 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本身也会带来耗时，而且在纳秒级别的测试中会显得非常明显

shell 复制代码

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

go 复制代码

// BenchmarkFibWrongA 演示了错误的基准测试代码，这样的测试可能无法结束
func BenchmarkFibWrongA(b *testing.B) {
	for n := 0; n < b.N; n++ {
		fib(n)
	}
}

上述代码在基准测试的时候可能永远不会结束，这是因为b.N的值并不固定，可能超出了fib方法的设计范围，这样就导致出现意料之外的结果（本意是性能测试，fib的入参应该是设计范围内的），实际运行效果如下，红色箭头指向的状态一直在等待中，只能强行关闭了
第二种反面教材也类似，不过更简单，直接拿b.N作为入参，只调用一次fib方法，代码如下所示

go 复制代码

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学习路上，欣宸一路相伴

欢迎关注博客园：程序员欣宸

学习路上，你不孤单，欣宸原创一路相伴...