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: <456C726B.3000003@sbcglobal.net>
Date: Tue, 28 Nov 2006 09:31:23 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: ArrayInputStream and performance
References: <x1o3k61mo4gs.fsf@sun.com> <wjo8wt5l9m8m.fsf@sun.com>
 <456B917F.4090706@apache.org> <wjo8r6vn501x.fsf@sun.com>
In-Reply-To: <wjo8r6vn501x.fsf@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Knut Anders Hatlen wrote:
> 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.
I put in a lot of the store inline optimization, regretting the 
"ugliness" of it at the time - but it was all driven by profiler results 
at the time.  When looking at it you
should realize it was tuned to the state of jvm's, probably 5 years ago.
Some may not be needed any more, but at the time these kinds of changes
helped the cached scan performance of the store by close to 10 times on
some hardware/jvm's.
> 
> 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().

It would be fine to use an unchecked and/or an ASSERT based check for
  readFieldLengthAndSetStreamPosition.  The "store" module owns this 
access and is not counting on limit checks to catch anything here.
>