optimize ReadBatch by moving memory allocation outside the loop rang…

[jdeisenh]

My use case is reading and processing lots of UDP multicast data ~ 3.5Gbps,
over 2M Packets per second.
This being UDP, the kernel will deliver one packet per buffer.
(GRO helps, but not much)
Using ReadBatch from golang.org/x/net/ipv4 should reduce syscall overhead.
Benchmarking this, I found that is slower than just using Read()
The current implementation of mmsghdr.pack() does allocate slices for every
buffer in the inner loop, which, at a rate of 3M pps, is a big performance limit.
( Side note: Even with this patch, ReadBatch is only a win if there is enough data to read in each call. In a tight loop, where only a few buffers are returned in each call, the overhead involved will make things worse than just using Read().)

Changes:
Simply moving the allocation out of the innermost loop will reduce the allocations by a significant amount if len(Messages) is large

Downsides:
Slightly less efficient with very small BatchLengths. But in this case, ReadBatch is already quite inefficient and should not be used

Further work:
There are still allocations for every call in ReadBatch, which is unnecessary. Changing this will need interface changes, because system specific data (iovec etc) needs to be stored somewhere.

[gopherbot]

This PR (HEAD: 415bc55) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/net/+/245162 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
A maintainer will review your change and provide feedback. See
https://golang.org/doc/contribute.html#review for more info and tips to get your
patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11 or adds a tag like "wait-release", it means that this CL will be
reviewed as part of the next development cycle. See https://golang.org/s/release
for more details.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/245162.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Go Bot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
A maintainer will review your change and provide feedback. See
https://golang.org/doc/contribute.html#review for more info and tips to get your
patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11 or adds a tag like "wait-release", it means that this CL will be
reviewed as part of the next development cycle. See https://golang.org/s/release
for more details.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/245162.
After addressing review feedback, remember to publish your drafts!

[costela]

howdy @jdeisenh! 😄
I believe this was solved in f8dd838, so this can maybe be closed?

(a bit impolite that your PR wasn't even answered 😒)