defer 的性能似乎没有想象中的差

[FishGoddess]

我看到文档中写用 defer 相差 20 倍性能，于是就做了个性能测试，看起来差距并不大 : )

BenchmarkMutexUnlock                    36646646                31.2 ns/op             3 B/op          1 allocs/op
BenchmarkMutexDeferUnlock           36638252                34.1 ns/op             3 B/op          1 allocs/op
BenchmarkRWMutexUnlock               27438340                43.2 ns/op             3 B/op          1 allocs/op
BenchmarkRWMutexDeferUnlock      27102475                44.6 ns/op             3 B/op          1 allocs/op
BenchmarkRWMutexRUnlock             38856032                30.8 ns/op             3 B/op          1 allocs/op
BenchmarkRWMutexDeferRUnlock    35632441                32.9 ns/op             3 B/op          1 allocs/op

以下是测试用例：

package bench

import (
	"strconv"
	"sync"
	"testing"
)

var (
	lock sync.Mutex
	rwlock sync.RWMutex
)

func testTask() {
	strconv.FormatInt(666, 10)
}

// go test -v -bench=^BenchmarkMutexUnlock$ -benchtime=1s
func BenchmarkMutexUnlock(b *testing.B) {
	task := func() {
		lock.Lock()
		testTask()
		lock.Unlock()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkMutexDeferUnlock$ -benchtime=1s
func BenchmarkMutexDeferUnlock(b *testing.B) {
	task := func() {
		lock.Lock()
		defer lock.Unlock()
		testTask()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkRWMutexUnlock$ -benchtime=1s
func BenchmarkRWMutexUnlock(b *testing.B) {
	task := func() {
		rwlock.Lock()
		testTask()
		rwlock.Unlock()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkRWMutexDeferUnlock$ -benchtime=1s
func BenchmarkRWMutexDeferUnlock(b *testing.B) {
	task := func() {
		rwlock.Lock()
		defer rwlock.Unlock()
		testTask()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkRWMutexRUnlock$ -benchtime=1s
func BenchmarkRWMutexRUnlock(b *testing.B) {
	task := func() {
		rwlock.RLock()
		testTask()
		rwlock.RUnlock()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkRWMutexDeferRUnlock$ -benchtime=1s
func BenchmarkRWMutexDeferRUnlock(b *testing.B) {
	task := func() {
		rwlock.RLock()
		defer rwlock.RUnlock()
		testTask()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

或许您也可以试试，看看 defer 的性能是否真的这么差 ~

PS: 其实内存操作本身就很快，如果追求极致性能，与其纠结 defer，倒不如放弃 fmt.Sprintf 😄

PPS: 这个获取时间的优化属实有点骚~

[orca-zhang]

理解gap而已，每个操作耗时都不一样，不是说增加defer会导致20倍性能损耗
可以用一个单独的空函数，用defer和非defer场分别测试一下

fmt.Sprintf或者fmt.Sprint在场景下不一定省的了的，提供interface{}类型的key性能会有下降
目前仅仅是所有参与测试的库都保持统一而已，并非所有场景都有整型的唯一字段
你的建议导致倒提醒我，可以考虑提供shim，把整型变成pseudo string当作key来用，这个我加一下，不过这个优化也是所有库都适用的，并不影响横向比较

[orca-zhang]

shim，把整型变成pseudo string当作key来用

已经提交代码，在跑bench了 : )

[FishGoddess]

我试了下，空函数也是差不多的，可能是 Go 对 defer 做了优化吧

package bench

import "testing"

// go test -v -bench=^BenchmarkFunc$ -benchtime=1s
func BenchmarkFunc(b *testing.B) {
	emptyFunc := func() {}
	task := func() {
		emptyFunc()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

// go test -v -bench=^BenchmarkDeferFunc$ -benchtime=1s
func BenchmarkDeferFunc(b *testing.B) {
	emptyFunc := func() {}
	task := func() {
		defer emptyFunc()
	}

	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		task()
	}
}

跑出来的结果是：

BenchmarkFunc-12                    772130599                1.49 ns/op            0 B/op          0 allocs/op
BenchmarkDeferFunc-12           431395675                2.75 ns/op            0 B/op          0 allocs/op

PS: 我不是说要提供 interface{} 的 key 哈，使用 string 本身没有啥问题，我是想说其实用户创建这个 key 的时候不用 fmt，而是直接拼接，省出来的性能可能远比库本身的性能要多 : )

PPS: 老哥，我非常赞同您的 “暴力美学”，毕竟 “完美的软件不是不能再加东西，而是不能再减任何东西”，所以我也一直在做减法，给 ecache 点个 star，做开源不容易，向你学习！（另外，毛老师真的是个老司机😏）

[orca-zhang]

ok，我调整一下readme，上面的优化从bench上看效果不大，数字也比较小，实际如果是uid之类的话，效果会有一些吧

你指的拼接具体是怎样的？

感谢建议～发完v1.1.0暂时不搞了，另一个存储项目耽搁好久了😅

[orca-zhang]

PPS: 这个获取时间的优化属实有点骚~

我优化完了写bench时候有看到hlts2/gocache用的kpango/fasttime里也是类似的思路，里面是5秒校准

本来打算在orca-zhang/chrono扩展的，后来想了一下，和time本身无法兼容，还没想好，后面再说吧

[FishGoddess]

ok，我调整一下readme，上面的优化从bench上看效果不大，数字也比较小，实际如果是uid之类的话，效果会有一些吧

你指的拼接具体是怎样的？

感谢建议～发完v1.1.0暂时不搞了，另一个存储项目耽搁好久了😅

拼接就是用 + 连接字符串哈哈，比如说这两种写法：

func productKey(productID int64) string {
    // return fmt.Sprintf("product:%d", productID)
    return "product:" + strconv.FormatInt(productID, 10)
}

用户想要性能的话，还是会选择用 + 拼接的，虽然可读性看起来没有 fmt 高 : )

PS: 我对存储软件也挺感兴趣的，一直想研究下，不耽搁您这边写存储项目了😅

[orca-zhang]

+会有临时对象产生，如果有格式化需求，用fmt.Sprintf感觉更合适，没仔细测试过，我在borm里面用的是StringBuffer，那个就太难看了，只能库里面用

啊，不是那个意思，不是说issue耽误我哈，只是感觉自己在优化上花的时间太久了，没符合预期，终于可以结束了

很可惜，kpango/fasttime作者写的宣称fastest的无锁cache被踢出bench列表了，因为实在太慢了😓

[FishGoddess]

+会有临时对象产生，如果有格式化需求，用fmt.Sprintf感觉更合适，没仔细测试过，我在borm里面用的是StringBuffer，那个就太难看了，只能库里面用

啊，不是那个意思，不是说issue耽误我哈，只是感觉自己在优化上花的时间太久了，没符合预期，终于可以结束了

很可惜，kpango/fasttime作者写的宣称fastest的无锁cache被踢出bench列表了，因为实在太慢了😓

我之前有测试过 + 拼接、Builder 以及 Buffer 的性能，在拼接数量多的时候确实 + 的性能差很多，但是在连接数量少的时候差别不大，而缓存 key 一般也就连接两三个字符串，所以用 + 也还好。倒是 fmt 性能消耗挺大的，毕竟用了反射操作。。。

话说回来，相比网络操作，这些都是小儿科哈哈

之前我优化一个日志库的时候就发现时间操作很耗时，当时用了类似缓存的方式去优化，结果性能测试惨不忍睹。。。负优化的一大惨案 😅

PS: 期待大佬的其他开源杰作！

[orca-zhang]

嗯，对的，之前在业务代码里面用fmt比较省事儿，周末看了strconv.FormatInt性能好很多。上周改用shim的方案，还多一次bytes转string，gc性能没法和freecache这种直接存bytes的PK，换成strconv.FormatInt好多了，目前是不同的库都用了更合适的方案。