Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Sun, 26 Nov 2006 19:11:38 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: ArrayInputStream and performance
In-reply-to: <x1o3slg8n2ep.fsf@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7psbat6w5.fsf@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <x1o3k61mo4gs.fsf@sun.com> <wjo8wt5l9m8m.fsf@sun.com>
 <x1o3slg8n2ep.fsf@sun.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (usg-unix-v)

Dyre.Tjeldvoll@Sun.COM writes:

> Knut Anders Hatlen <Knut.Hatlen@Sun.COM> 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