tree 60ffac49c43b5a50f37be6b7e4c29ea5778fdc1d
parent 1e9c692c171e8adc819b3c55bf84ceaa06587f1a
author Alessandro Ghedini <alessandro@ghedini.me> 1601567613 +0100
committer GitHub <noreply@github.com> 1601567613 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJfdft9CRBK7hj4Ov3rIwAAdHIIAGdBjjGaIMJXfqkbMbttpqQM
 PPi5qjpUy4x3aO5u0CdwvLno+v/D9ubWqaiaOJJ7/rfAmmCl6+79/GK5hoA8yuOF
 3KR87zl3tj1npDZeyewO2fToUu8c9UhUYUBWxQ4bSvtVMLfv2EOCin5OKdtWPosT
 LjdbDRBzPchmYPYIE4u0VXRJrqRyBAQLthirWhXGec2pkQBKh8VsXQfZvecIbCgi
 HdbRKgH2BMHVNFrkGTRoQRmKbwyL8bCdFx/aRdpglH/TetT4IRTwQQ6sO64Q6Trv
 k6NnbnWtj57ENb1WJ3lU0PZu0WWtze0lBzcNH6SJMC/adl2PZb5+b8asu146xXE=
 =VRCr
 -----END PGP SIGNATURE-----
 

stream: allow RangeBuf to be partially consumed without splitting (#643)

When "popping" a RangeBuf that exceeded the maximum capacity of the
output buffer, we would simply split-off the internal buffer up to the
maximum cap, and then push a new RangeBuf back into the send or recv
buffer.

This is inefficient for two reasons:

1. Splitting off a Vec means duplicating the remainder of the buffer
   into a new Vec. Depending on the size of the original buffer this
   could be very expensive, which is why we had a hack to split-off
   buffers received by the application before creating the original
   RangeBuf.

2. Pushing back the new RangeBuf into the send or recv buffer is
   potentially expensive as a binary heap is used.

The new popping implementations allow for a RangeBuf to be partially
consumed at its start, without the need for splitting it off.

The downside is that the "consumed" bytes will only be freed when the
whole RangeBuf is consumed, but that should be fine.