perf: switch out pull-block for bl

[achingbrain]

Swaps out pull-block for bl

• We could see a bit more of a gain by using bl.shallowSlice in the this.queue calls but it returns instances of BufferList instead of Buffer. These fail Buffer.isBuffer which is used by the protons module further down the pull-stream pipeline so until we refactor or replace we can't use it. Thankfully we have forked protons so can improve it, though in WIP: new ipld format api ipld/js-ipld-dag-pb#105 @vmx has started to use pbf instead of protons so we'll have to examine the performance impact of that change.
• When we've consumed part of the buffer we can either call bl.consume to remove the bytes from the front of the buffer list, or just create a new buffer list and slice in the bytes we've yet to consume - from my testing, creating a new buffer list was faster so that's what this PR does. Using bl.consume was a little slower than using pull-block.

Results (lower is better):

• bl.consume was about 1% slower than pull-block
• newing up BufferLists and bl.shallowSliceing to remove consumed data was about 12% faster than the current pull-block based implementation

It uses the test from #11

[achingbrain]

cc @mcollina

[mcollina]

Can you do a flamegraph of that benchmark?

The constructor of bl initialize a readable stream, and that is not cheap. You might want to send a PR to BL to move to a lazy-initialization, like we do in core for some modules: https://github.com/nodejs/node/blob/master/lib/internal/streams/lazy_transform.js.

Alternative, introduce a require('bl/compact') that does everything that BL does, minus the streams (and play some prototype magic to avoid code duplication). I'm a maintainer of BL, and I think I can get that out quickly (2-3 days after I'm back from vacation).

[achingbrain]

@mcollina download it and take the .txt extension off: flamegraph.html.txt

[mcollina]

Just checked, all is well and Readable initialization is not an issue.

I concur that using shallowSlice instead of slice while enqueuing would lead to a performance improvement, especially if protons could understand and compose its messages using BL as well.

[mcollina]

LGTM

[achingbrain]

Readable initialization is not an issue

It didn't seem that way to me either.

I concur that using shallowSlice instead of slice while enqueuing would lead to a performance improvement

I hacked in support for Buffer-like objects to protons quickly locally so we can use shallowSlice:

Like this bl with slice is 12% faster than pull-block, with shallowSlice it's more like almost 19% faster, so worth doing!