[Performance] Large Object's Input Stream (BlobInputStream) takes a lot of time due to read one by one in application level

[inhabitantNewCity]

fix performance issue described below
#2374 (comment)

[vlsi]

PS. It would be great if you could create PRs using a feature-branch.
PRs from a master branch do not really work great, especially, if you have multiple PRs.

[vlsi]

@inhabitantNewCity , it looks like the PR won't handle the case when the client mixes .read() and .read(byte[]... calls.
Would you please add a test so the stream is processed with various APIs to ensure the buffers work properly?

There's already StrangeInputStream to cover that case, however, it looks like .read() is missing there.

[inhabitantNewCity]

it is covered by Code (because I reuse the same variables in buffered read)
I will add additional test for check such case. thank you.

about Feather branch, Could I use master for this issue?
I will use separate branch for next features

[vlsi]

Keeping this in master is just fine.

[davecramer]

It's going to be quite complicated to keep both of these implementations.

Scenario 1 . read() is called first and there is data in buffer, next read(b,o,l) is called, one would have to copy the buffer in first and start reading from that point on adjusting the offset and length. (This may be all that is required)

Scenario 2). read(b,o,l) is called first, I guess all that is really necessary is to update apos.

I'm not sure exactly why there is a limit at all, that seems rather pointless.

[inhabitantNewCity]

yes, I found bug with mixed access, but I want to make it simplified if user call read() that system will redirect to previous approach like:

 if (bpos != 0) {
      return super.read(buf,off,len);
    }

@vlsi @davecramer What do you think?
Because such mixing looks like weird. it is really special case :) and I afraid that such case will bring huge CPU consumption to fully support such case .

about limit, yes I agree, as for me it is over complicated to support partial read and not so useful

[davecramer]

I'm thinking something more like PR #2376

[vlsi]

I'm closing the PR as the fix will be available in 42.7.1, see #3044