Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <456B917F.4090706@apache.org>
Date: Mon, 27 Nov 2006 17:31:43 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: ArrayInputStream and performance
References: <x1o3k61mo4gs.fsf@sun.com> <wjo8wt5l9m8m.fsf@sun.com>
In-Reply-To: <wjo8wt5l9m8m.fsf@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Knut Anders Hatlen wrote:

> 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);
>   }


I could only find one method that looked something like the above:

StoredFieldHeader.readFieldLengthAndSetStreamPosition

Could you provide a list of the others so I can see what the issue is?

Thanks,
Dan.


> 
> 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?
>