db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: ArrayInputStream and performance
Date Mon, 27 Nov 2006 15:56:29 GMT
I am not sure I understand what is being proposed here.  Is the idea
that in a delivered system the checks will not be done, or does
replacing it by ASSERTS mean that the check is done differently.

I know store uses a lot of this code, and there is some inline
code in this exact area for performance reasons.  At one level of
the store engine it "knows" that what it is acting on is a byte
array and at least back when the work was done it was a big performance
improvement - but at other levels of access it is only an 
ArrayInputStream.  Part of this also comes from allowing alternate
module implementations.

Knut Anders Hatlen wrote:
> 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
>>>  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.

View raw message