关于shardmap中size大小的调整

[liu-song]

目前shardmap的分片size 是 直接由本机的核心数决定的；

var ShardSize int

func init() {
	ShardSize = runtime.GOMAXPROCS(0)
}

我自己测了一下，就是将 netpollmux/shard_map_test.go 中的 size大小 调整了下
func BenchmarkSharedMap2(b *testing.B) {
	m := newSharedMap(2)
	var key int32
	var mod int32 = 1023
	b.ReportAllocs()
	b.StartTimer()
	b.SetParallelism(Parallelism)
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			key := atomic.AddInt32(&key, 1) & mod
			m.store(strconv.Itoa(int(key)), nil)
			m.load(strconv.Itoa(int(key)))
		}
	})
}
删除了delete,大致相当于读写比例1:1,测试结果如下
goos: windows
goarch: amd64                                              
cpu: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz             
BenchmarkSyncMap                                           
BenchmarkSyncMap-8               1490757               716.7 ns/op           130 B/op          4 allocs/op
BenchmarkMutexMap                                                                                         
BenchmarkMutexMap-8              1390027               764.5 ns/op           106 B/op          2 allocs/op
BenchmarkSharedMap2
BenchmarkSharedMap2-8            3857847               363.3 ns/op             6 B/op          1 allocs/op
BenchmarkSharedMap4
BenchmarkSharedMap4-8            2189890               524.7 ns/op           129 B/op          2 allocs/op
BenchmarkSharedMap8
BenchmarkSharedMap8-8            3185452               338.1 ns/op            97 B/op          2 allocs/op
BenchmarkSharedMap16
BenchmarkSharedMap16-8           4114696               301.2 ns/op           136 B/op          2 allocs/op
BenchmarkSharedMap32
BenchmarkSharedMap32-8           4931204               270.4 ns/op           116 B/op          2 allocs/op
BenchmarkSharedMap64
BenchmarkSharedMap64-8           4932050               256.5 ns/op           116 B/op          2 allocs/op
BenchmarkSharedMap128
BenchmarkSharedMap128-8          5030550               220.3 ns/op           114 B/op          2 allocs/op
BenchmarkSharedMap256
BenchmarkSharedMap256-8          5132156               216.8 ns/op           113 B/op          2 allocs/op
BenchmarkSharedMap512
BenchmarkSharedMap512-8          4682668               220.5 ns/op           122 B/op          2 allocs/op
BenchmarkSharedMap1024
BenchmarkSharedMap1024-8         4866469               220.2 ns/op           118 B/op          2 allocs/op

可以看到分片大些效果要好些，但也没有必要太大，目前没有经过其他方面的充分测试，这个size 做个如下的调整，是不是会更好一些？

ShardSize = runtime.GOMAXPROCS(0)*16 或者8 

这样调整之后，ShardSize 也能确保是2的倍数了，在getShard 的时候也可以将求余改成位运算

func (m *shardMap) getShard(seqID int32) *shard {
	return m.shards[abs(seqID)&(m.size-1)]
}

[Hchenn]

1. benchmark 理论上是局部最优的，在 kitex-benchmark 测试上，ShardSize = N x runtime.GOMAXPROCS(0) 没有看到明显的收益，应该不是主要瓶颈，实际的处理情况，并发竞争没有 benchmark 那么多，从内存角度考虑，感觉当前 size 是够用的。
2. 取模运算也是很快的，通过简单 benchmark 比较，和位运算也没有明显差别，改为取模是为了兼容非二次幂的情况。

感谢，以上两个问题我们都评估过，在历史版本上的做法也是如你所述，当前版本做法是思考后做出的改变。