db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: ArrayInputStream and performance
Date Tue, 28 Nov 2006 10:37:46 GMT
Daniel John Debrunner <djd@apache.org> writes:

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

You are quite right; most of the methods that inline the accesses
don't call setPosition(). I think I must have confused the callers of
ArrayInputStream methods with the internal implementation of
ArrayInputStream. They use a pattern of first copying the instance
variables into local variables, then do the work on the local
variables, and finally write back to the instance variables. While I
find that a little confusing because I would expect the run-time
compiler to be able to perform that kind of optimization itself,
that's a different issue from what is discussed in this thread.

The mentioned method (readFieldLengthAndSetStreamPosition) seems to be
the one that causes most calls to ArrayInputStream. All of the calls
are to setPosition(). If the boundary checking in setPosition() has an
unreasonably high resource consumption, it is always an option to
check the usages of readFieldLengthAndSetStreamPosition, and if it can
be proven safe to skip the boundary checking, that method could use an
unchecked variant of setPosition().

Knut Anders

View raw message