在go 1.17 Version中使用工作池的性能比不使用池要低

[zbh255]

代码:event_poll/internal/work_pool_test.go

goos: darwin
goarch: amd64
pkg: github.com/zbh255/nyan/event_poll/internal
cpu: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz
BenchmarkTask
BenchmarkTask/NoWorkerPool
BenchmarkTask/NoWorkerPool-8         	      49	  22029490 ns/op	 2411937 B/op	  100028 allocs/op
BenchmarkTask/UseWorkerPool
BenchmarkTask/UseWorkerPool-8        	      21	  68326205 ns/op	 2402624 B/op	  100035 allocs/op
PASS

简单的实现对资源消耗和性能都似乎没有任何帮助，有些复杂的实现可以帮助减少资源。
之后在琢磨下工作池的实现

[zbh255]

经过测试证明，当初的测试代码不足以体现WorkerPool的优势
https://github.com/zbh255/nyan/blob/2eab3608a0957aa84ae3a8f6e0118d97c53bbf36/event_poll/internal/worker_pool_test.go#L58
原子增加的速度很快，这样会使goroutine很快进入Gdead状态，而这些死掉的goroutine被缓存起来很快就会重新投入使用，而channel的锁竞争似乎也是一大问题，在pprof视图中，它占据了大约30%的cpu time，我们应该编写一些现实一点的测试来测试Worker-Pool，所以我重新编写了测试文件。顺便重构了worker-pool，使它比原来更高性能。

[zbh255]

新的提交: f9bc5c6
测试代码中使用了不同的测量代码
net.Conn.Close来模拟连接因到达deadline而调用Close的行为
https://github.com/zbh255/nyan/blob/f9bc5c60ef39ee51f92185262792622bd3818969/event_poll/internal/worker_pool_test.go#L85
sleep则让众多goroutine挂起
https://github.com/zbh255/nyan/blob/f9bc5c60ef39ee51f92185262792622bd3818969/event_poll/internal/worker_pool_test.go#L51

[zbh255]

新的测量结果中使用了比之前更加丰富的bench参数

 go test -v ./... -bench=. -benchmem -cpu 1,4,8 -benchtime 10s

该视图的一些测量参数

• 关闭10000个socket
• 统计1000000个goroutine睡眠10ns的结果

goos: darwin
goarch: amd64
pkg: github.com/zbh255/nyan/event_poll/internal
cpu: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz
BenchmarkTask
BenchmarkTask/NoWorkerPool
BenchmarkTask/NoWorkerPool                    54        1041306504 ns/op        96872308 B/op    2001892 allocs/op
BenchmarkTask/NoWorkerPool-4                  50         225670590 ns/op        96000111 B/op    2000002 allocs/op
BenchmarkTask/NoWorkerPool-8                  52         233952806 ns/op        96000338 B/op    2000004 allocs/op
BenchmarkTask/UseWorkerPool
BenchmarkTask/UseWorkerPool                   40         361620237 ns/op            1007 B/op          3 allocs/op
BenchmarkTask/UseWorkerPool-4                 43         274930788 ns/op             939 B/op          3 allocs/op
BenchmarkTask/UseWorkerPool-8                 43         277646598 ns/op             941 B/op          3 allocs/op
BenchmarkSocketClose
BenchmarkSocketClose/NoPoolRead
BenchmarkSocketClose/NoPoolRead             1470           7980318 ns/op         1280000 B/op      30000 allocs/op
BenchmarkSocketClose/NoPoolRead-4           4486           2960468 ns/op         1280051 B/op      30000 allocs/op
BenchmarkSocketClose/NoPoolRead-8           3730           3354753 ns/op         1280022 B/op      30000 allocs/op
BenchmarkSocketClose/UsePoolRead
BenchmarkSocketClose/UsePoolRead            5052           2657140 ns/op          800003 B/op      10000 allocs/op
BenchmarkSocketClose/UsePoolRead-4          4208           2791945 ns/op          800012 B/op      10000 allocs/op
BenchmarkSocketClose/UsePoolRead-8          4218           3013337 ns/op          800012 B/op      10000 allocs/op
PASS
ok      github.com/zbh255/nyan/event_poll/internal      318.595s

[zbh255]

虽然还是比不上raw scheduler，但可以看到，差距比之前小了很多，内存分配情况也得到了优化。
go的内存分配器对堆上的小对象有特殊优化，这种情况下的内存分配优化没什么作用，但这个问题还没有结束，还有很多东西没有弄明白。