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: Tue, 28 Nov 2006 11:59:38 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-2118) Change some boundary checks in
 ArrayInputStream to ASSERTs to improve performance
In-reply-to: <18318719.1164677841584.JavaMail.jira@brutus>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <wjo8k61f4z1h.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <18318719.1164677841584.JavaMail.jira@brutus>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (usg-unix-v)

"Daniel John Debrunner (JIRA)" <jira@apache.org> writes:

> Also how can these methods take up 1.5% of system time, since they
> are just modifying instance fields, isn't that all user code?

"Dyre Tjeldvoll (JIRA)" <jira@apache.org> writes:

> Wrt. system cpu: I think that's strange too, but that is what the
> profiler says. Maybe it is wrong. (it attributes the system cpu (and
> most of the user cpu too) to the byte code line doing getfield #11,
> which I think is ArrayInputStream.end

I'm just guessing here, but embedded Derby should use very little
system CPU (at least for read-only load, all data in page cache and
only one client, which I assume is the configuration used). 1.5% of a
number that is very small in the first place, is very close to
nothing. Since this is some of the code that is executed most
frequently, background noise might be accumulated there. I don't know
what that background noise might be, but perhaps cache misses or
involuntary context switches use system CPU?

Does your profiler say how much of the total CPU time is system time?

-- 
Knut Anders