开始煎鱼大佬和无闻大佬在讨论go-ini/ini这个库为什么不加个WatchConfig的功能呢?一个加载配置文件的另一个库viper有类似的功能。其实这个也很常见,基于业务需求,不用修改代码, 修改一下配置文件即可实现热更配置的要求。以下是大佬们的对话:




无闻大佬

煎鱼大佬

无闻大佬:

煎鱼大佬:



于是无闻大佬抛出了自己的benchmark的结果。代码路径在https://github.com/go-ini/ini/blob/d4cae42d398bc0095297fc3315669590d29166ea/bench_test.go,主要看Direct方法的性能


benchmark的效果如下:

image.png


小弟我就问了一句 这个benchmark的默认时间是10s吧 (原来是一秒,我之前还总结过,真是老了记忆越来越不好了),benchmark的源码在 https://golang.org/src/testing/benchmark.go。benchTime的定义如下:


1benchTime = benchTimeFlag{d: 1 * time.Second} // changed during test of testing package


于是小弟也看了下自己在在go test这块的总结,go test 中 -benchtime flag的说明,默认确实是1s。


1-benchtime t
2Run enough iterations of each benchmark to take t, specified as a time.Duration (for example, -benchtime 1h30s). The default is 1 second (1s).


讨论完这个后,我把之前压测zap的Info性能的结果放了出来


image.png


无闻大佬用这个命令测试了一番,发现差距特别大,结果差了20倍之多。最后得知无闻大佬用的命令如下,原来是加了race竞态检测。

1$go test -v -cover -race -test.bench=. -test.benchmem


image.png


最后发现加上race会使内存占用和执行时间增加好多倍,Go官方Blog中Golang race detection写到


1The cost of race detection varies by program, 
2but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x.


关于加上race为何会有如此多的性能消耗,找了一些资料了解到, race 检测的一些函数是由汇编实现的,当开启-race时raceenabled会为true,从而会对一些竞态资源进行检测。官方readme中关于race的解释是


1runtime/race package contains the data race detector runtime library.
2It is based on ThreadSanitizer race detector, that is currently a part of
3the LLVM project

最后推荐几篇关于race的文章

  1. Race源码
  2. Go 译文之竞态检测器 race[官方blog]
  3. Data Race Detector[官方blog]
  4. Golang race detection
  5. Data races in Go(Golang) and how to fix them
  6. go run -race的底层实现 [📎Strangeloop_final.pdf]