proposal: io: add ReadPeeker and implement Peek in bytes.Reader

[mhr3]

Is there any reason why bytes.Reader doesn't have a Bytes() or Next(int) method similar to bytes.Buffer?

Such a method would allow zero-copy usage of bytes.Reader, cause currently all public methods require a separate buffer to copy the data into. Plus these methods already exist on bytes.Buffer, so gophers are already familiar with them.

[ianlancetaylor]

The point of bytes.Reader is that you have a function that takes an io.Reader, and you have a []byte, and you want to pass the []byte to the function. Therefore, bytes.Reader has all the methods that that function might want to call. That function isn't going to call a Bytes or Next method, because those aren't implemented by other io.Reader values.

To put it another way, if you feel a need to call a Bytes or Next method, why not just work with the original []byte directly?

[mhr3]

It's a common optimisation pattern to check for specific types inside functions that work with interfaces, therefore any function which accepts an io.Reader could have a fast-path for bytes.Reader if it were possible to get to the byte slice from the Reader.

[ianlancetaylor]

Can you point us to some existing code that would take advantage of this optimization? Thanks.

[mhr3]

Pretty much any streaming parser, even stdlib's bufio.Reader could have a special case for the reader being bytes.Reader avoiding copying everything.

[Jorropo]

You could implement this today using .WriteTo, it has a few ergonomics issue, mainly require moving some processing in a callback and does not work if you don't plan on consuming the full data. However it is already widely deployed solution for zero-copy.
Depending how disruptive you allow it to be you can always refactor your data pipeline to be inverted and fit in there.

[mhr3]

So I've tried to showcase this in master...mhr3:go:bytes-reader-next

I've added bytes.Reader.Next and adapted bufio.Reader to use the byte slice directly, while not exactly pretty (and I'm not proposing stdlib should do this), it shows how such an API could be used and mainly this is not possible without this new API.

Also result of benchstat of a very simple benchmark in the bufio package (master vs this branch):

name                old time/op    new time/op    delta
ReaderReadString-8    50.8ns ± 0%    44.9ns ± 0%  -11.74%  (p=0.000 n=10+10)

name                old alloc/op   new alloc/op   delta
ReaderReadString-8      144B ± 0%      144B ± 0%     ~     (all equal)

name                old allocs/op  new allocs/op  delta
ReaderReadString-8      1.00 ± 0%      1.00 ± 0%     ~     (all equal)

While preparing this benchmark result, I also realised strings.Reader should have the same Next() method.

[dsnet]

The github.com/dsnet/compress module looks for types that implement Buffered, Peek, and Discard methods to perform zero-copy decompression from some input. This provided quite a substantial speed-up for decompression.

At present, the bufio.Reader and bytes.Buffer types provide some mechanism to at least implement zero-copy optimizations, but bytes.Reader provides no API to get at the underlying []byte. Adding it would make the API less safe, but not any less safe than bytes.Buffer and bufio.Reader. Also, it would make the bytes.Reader API inconsistent with strings.Reader.

That said, it'd be nice if there was a unified API for copy-less reads. Since Buffered, Peek, and Discard methods already exist, maybe we should rally around those?

[mhr3]

I think the Next() method suits better for this (given no IO needs to happen, so there's no potential for an error happening, plus the simplicity), but ultimately I don't have a strong opinion, as long as there's a way to do this - Bufferred() + Peek() + Discard() would do the trick too.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group