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: Fri, 24 Nov 2006 11:23:37 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: ArrayInputStream and performance
In-reply-to: <x1o3k61mo4gs.fsf@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <wjo8wt5l9m8m.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>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (usg-unix-v)

Dyre.Tjeldvoll@Sun.COM writes:

> I have noticed that two methods, setPosition(int) and setLimit(int)
> seem to use more CPU than what I find "reasonable" given what they're
> supposed to do. Together they use 4.5% of user CPU and 1.5% of system
> CPU. 
>
> Looking closer at what each method does, it seems like a fair amount
> of the CPU is on argument/consistency checking. 
>
> For setPosition(int) it seems simple to replace the checking with
> an ASSERT, but in setLimit(int) a failed check will cause 'start', 'end'
> and 'position' to be set to 0 before an exception is thrown:
>
>         start = position;
>         end   = position + length;
>
>          if (end <= pageData.length)
>          {
>              return;
>          }
>          else
>          {
>  			start = end = position = 0;
>  			throw new EOFException();
>          }
>
> Does anybody know if there is code that catches this exception and
> that relies on these variables being set to 0?

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?

-- 
Knut Anders