Use Buffer.allocUnsafe to reduce allocations and CPU usage

[chkimes]

Buffer.allocUnsafe will prefer to create non-zeroed buffers using the buffer pool rather than creating a new zeroed buffer each time like Buffer.alloc. Despite the name, Buffer.allocUnsafe is safe to use if you are immediately overwriting all the content in the buffer, and it is preferred for library APIs that will be called a lot or will be doing a lot of allocations.

https://nodejs.org/api/buffer.html#static-method-bufferallocunsafesize

[kibertoad]

@Uzlopak I summon thee, the master of Node.js performance

[Uzlopak]

@kibertoad

Well yes it is better. We have just to make sure that we always completely write the Buffer.

[chkimes]

At least in these two instances where the buffers are created, the lengths are known ahead of time and the new buffers are immediately filled with data.

[cressie176]

Seems reasonable to me. I think it's worth adding a comment above each usage of allocUnsafe linking to this PR to discourage someone getting unnecessarily concerned, or worse, accidentally replicating when the buffers are not immediately filled. Unless any objections I'll merge and publish this weekend.

[chkimes]

I can update the PR with appropriate documentation. Linking this PR is probably unnecessary, since it should be already tied to the commit and findable for anyone who wants to review the surrounding context?

[cressie176]

I can update the PR with appropriate documentation. Linking this PR is probably unnecessary, since it should be already tied to the commit and findable for anyone who wants to review the surrounding context?

Thanks @chkimes, I see you've added a comment. A link to the PR is preferred because then people can easily find a whole discussion. I understand you could find this from the commit, but without a hint in the code it might easily be missed. I can easily sort after I merge though.

[Uzlopak]

Btw. Good job

[cressie176]

I decided to keep the original comment, but added a link to the PR too. Publishing as amqplib@0v.10.2 shortly. Thank you @chkimes and @Uzlopak