This bug was introduced by me in 8487663cad981e570cb46ad9560e0aec7f8db778 and I'm deeply sorry for that. The problem is that as the DatagramMessage channel is buffered we cannot simply use the same buffer for reading all incoming datagrams, because reading will change the []byte for all messages still buffered in the channel.
I added some tests that fail on the previous version in the hope of avoiding this same mistake in the future.
The solution was using a sync.Pool instance to acquire a buffer and putting it back on the pool only once it's been received and processed. This solution has the same advantages of reusing the buffer without the risk of changing a buffer still in use. And for some reason it seems even faster than simply using the same buffer:
benchmark old ns/op new ns/op delta
BenchmarkDatagramNoFormatting-4 2693 2398 -10.95%
benchmark old MB/s new MB/s speedup
BenchmarkDatagramNoFormatting-4 17.45 19.59 1.12x
benchmark old allocs new allocs delta
BenchmarkDatagramNoFormatting-4 4 5 +25.00%
benchmark old bytes new bytes delta
BenchmarkDatagramNoFormatting-4 368 487 +32.34%
This bug was introduced by me in 8487663cad981e570cb46ad9560e0aec7f8db778 and I'm deeply sorry for that. The problem is that as the DatagramMessage channel is buffered we cannot simply use the same buffer for reading all incoming datagrams, because reading will change the []byte for all messages still buffered in the channel.
I added some tests that fail on the previous version in the hope of avoiding this same mistake in the future.
The solution was using a sync.Pool instance to acquire a buffer and putting it back on the pool only once it's been received and processed. This solution has the same advantages of reusing the buffer without the risk of changing a buffer still in use. And for some reason it seems even faster than simply using the same buffer: