Optimise ring.DoBatch()

[bboreham]

ring.DoBatch contributes 20% of the memory allocation in my production distributors.

I started looking at this and realised the existing benchmark was not exercising the functionality - the cas() didn't update the ring so it was actually empty, and some test fixture code was also quite far up the profile.

Having fixed all that and made the benchmark call the higher-level function DoBatch(), the numbers before are:

BenchmarkBatch10x100-2     	   10000	    175156 ns/op	   56648 B/op	     334 allocs/op
BenchmarkBatch100x100-2    	    5000	    256146 ns/op	   87675 B/op	     720 allocs/op
BenchmarkBatch100x1000-2   	    1000	   1838020 ns/op	  578726 B/op	    3278 allocs/op

after:

BenchmarkBatch10x100-2     	   10000	    149385 ns/op	   12061 B/op	      29 allocs/op
BenchmarkBatch100x100-2    	   10000	    208285 ns/op	   30909 B/op	     238 allocs/op
BenchmarkBatch100x1000-2   	    1000	   1558331 ns/op	  112601 B/op	     217 allocs/op

The ReadRing function signatures have changed a bit, which may impact downstream projects using this code.

[tomwilkie]

Nice set of optimisations! Sorry I've been so nit picky.

Once small concern: we're now taking a (read) lock in a loop. Not super concerned about consistency (the ring might update mid processing a batch) but do you think this will impact CPU usage?

[bboreham]

do you think this will impact CPU usage?

The benchmarks show that CPU overall comes down. Profiling suggests that sort.Search() looking for each token is far more CPU-intensive than the lock.

I have addressed review comments; PTAL.

[gouthamve]

Nice, I've given a shot at optimising this a little while ago but couldn't get any gains, this is a nice approach!