> I think single roundtrip to the server to query the length is nothing
> against at least 125 to read the 2M BLOB (with default 16kb chunk
> size).

But when we talk about small BLOBs, we decrease the performance...

> And it allows to exclude memory reallocations - ByteArrayOutputStream
> reallocates new byte array with double size each time the buffer size is
> exceeded. And finally the whole 2Mb buffer is copied inside toByteArray().
> Also all ByteArrayOutputStream methods are synchronized.

Yes, this is the issue. I will think about possible improvement.

> Yes, in test application with 1..2 Mb BLOBs it is about 1.5 times
> faster. In real application it is difficult to measure as it depends
> on number of concurrent users, memory load, etc. Extra memory
> reallocations can trigger the GC, with additional slowdown.

This is also true. We had a "new byte[32768]" in one place in driver, that
slowed down the driver almost twice.

> I think it will be better to have getBytes() with predictable
> performance for all cases, and getInputStream() allowing developer to
> exclude additional roundtrip.

There is one issue here - there are applications that use getBytes() for
small BLOBs, changing this behavior to include one roudtrip will change its
behavior. Also, personally I would expect that applications fetching big
BLOBs would use getBinaryStream(), since I want to control the memory
allocation in my application.

So, currently I see only one possibility - to add one more property that
would allow memory allocation in the driver - something like
"fetchBlobsAtOnce" or something similar...

Roman