优化MultiBulkReply.ToBytes中计算所需内存的算法,提高性能

[ragong]

提交说明

本次提交主要是优化MultiBulkReply.ToBytes()方法;通过进来减少不必要的内存分配和字符串转换/拼接操作,从而提高性能和MultiBulkReply返回值的吞吐率;经过测试,对返回大批量数据的时候(例如LRANGE),性能提升明显.测试结果如下.

功能和benchmark测试 utils_test.go

测试结果

goos: windows
goarch: amd64
pkg: github.com/hdt3213/godis/lib/utils
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Benchmark_Itoa_20bit
Benchmark_Itoa_20bit-12                 21663034                57.17 ns/op
Benchmark_GetIotaLen_20bit
Benchmark_GetIotaLen_20bit-12           39857972                28.99 ns/op
Benchmark_Itoa_10bit
Benchmark_Itoa_10bit-12                 29314266                39.26 ns/op
Benchmark_GetIotaLen_10bit
Benchmark_GetIotaLen_10bit-12           130224921                9.493 ns/op
PASS

Process finished with the exit code 0

总结:采用新的方法可以一定程度上提升效率;但是在总体吞吐量测试上,表现不明显;经过分析,吞吐率受内存分配影响最大,这部分优化对总体影响较小.

[ragong]

PR中描述有误,应该为：
优化MultiBulkReply.ToBytes中计算所需内存的算法,提高性能;在utils中新增GetItoaLen方法,以替代原len(strconv.Itoa(i int))计算数字被转换为字符串以后字符串的长度;

[HDT3213]

这个优化就不必了吧，影响很小。不过你可以试试在 parser 或者 reply 的时候加个对象池，说不定效果不错

[ragong]

这个优化就不必了吧，影响很小。不过你可以试试在 parser 或者 reply 的时候加个对象池，说不定效果不错

嗯，是的。实测影响很小。我在在reply时加了对象池测试了，效果也不很明显。最大的开销仍然是网络IO