[EMAIL PROTECTED] writes:
> Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
>
>> I can't answer your question, but I will add that I find much of the
>> code that uses ArrayInputStream very confusing. ArrayInputStream is
>> supposed to wrap a byte array to provide encapsulation and easy access
>> to the data through the InputStream interface. However, many (most?)
>> of the callers inline the accesses to the data (presumably for
>> performance reasons), so we end up with lots of methods looking like
>> this:
>>
>> public X readSomething(ArrayInputStream ais, byte[] data, int offset...) {
>> // lots of direct manipulation of the byte array
>> // ...
>> // ...
>> // ...
>> // finally, make sure that the state of the stream is brought to a
>> // consistent state:
>> ais.setPosition(offset + numberOfManipulatedBytes);
>> }
>>
>> Both the byte array and the offset are part of the ArrayInputStream
>> class, so having all three of them in the parameter list feels a bit
>> ugly. And if we need to manipulate the internal state directly that
>> often, perhaps an InputStream is not the best data structure in the
>> first place?
>
> I tend to agree. I just finished running derbyall with the checks
> replaced by ASSERTs and I saw no failures. So unless I hear strong
> objections I'll create a Jira for this change.
FYI, I just ran the DERBY-1961 test clients and traced them with a
DTrace script that printed how often each method was called. For the
join client, ArrayInputStream.setPosition() was the most frequently
called method (43837.7 calls/tx). For the single-record select client,
it was third (58.4 calls/tx), only beaten by Object.<init>() and
DDMWriter.ensureLength(). I think this means that setPosition() is the
engine method that is most frequently called, at least in read-mostly
transactions. ArrayInputStream.setLimit() also appeared near the top
of the list. See http://wiki.apache.org/db-derby/Derby1961MethodCalls
for the details.
--
Knut Anders
