There has been recent discussion on the Architect list about batching
commands sent to the server.
If this ever happens, then getBlob() could also include a query for the
length of the blob as part of its series of commands.

-----Original Message-----
From: Firebird-Java@yahoogroups.com
[mailto:Firebird-Java@yahoogroups.com] On Behalf Of Alexey Panchenko
Sent: Thursday, December 29, 2005 8:26 AM
To: Roman Rokytskyy
Subject: Re[2]: [Firebird-Java] FBBlobField.java.patch

Roman Rokytskyy wrote:

>> + final int length = (int) blob.length();

> This call is additional roudtrip to the server, which quite often is
> more expensive than allocating byte arrays in VM. Anyway, server send
> data in chunks, max. of 64k size (and it is controlled by the
> blobBufferSize property), so reading it into one big array instead of
> reading it in small chunks should not be faster since it will be the
> same amount of roundtrips to the server.

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).
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.

> Did you see increase in performance?

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.

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

--
Best regards,
Alexey mailto:alex+news@...





Yahoo! Groups Links