Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <225298027.1222375424253.JavaMail.jira@brutus>
Date: Thu, 25 Sep 2008 13:43:44 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3882) Expensive cursor name lookup in
 network server
In-Reply-To: <1547050343.1222373386421.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634607#action_12634607 ] 

Knut Anders Hatlen commented on DERBY-3882:
-------------------------------------------

A simple hack that seems to reduce the cost of lookupCursorActivation() to some degree, is to compare the hash codes of the cursor names before we compare the full strings. That is, change "if (cursorName.equals(executingCursorName))" to "if (cursorName.hashCode() == executingCursorName.hashCode() && cursorName.equals(executingCursorName))". The reason why this is cheaper, is that most implementations of the String.hashCode() cache the hash value, so after the warmup it is not necessary to read the contents of the strings, and we only call String.equals() if there is a name collision.

> Expensive cursor name lookup in network server
> ----------------------------------------------
>
>                 Key: DERBY-3882
>                 URL: https://issues.apache.org/jira/browse/DERBY-3882
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server, Performance, SQL
>    Affects Versions: 10.4.2.0
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>
> I have sometimes seen in a profiler that an unreasonably high amount of the CPU time is spent in GenericLanguageConnectionContext.lookupCursorActivation() when the network server is running. That method is used to check that there is no active statement in the current transaction with the same cursor name as the statement currently being executed, and it is normally only used if the executing statement has a cursor name. None of the client-side statements had a cursor name when I saw this.
> The method is always called when the network server executes a statement because the network server assigns a cursor name to each statement even if no cursor name has been set on the client side. If the list of open statements is short, the method is relatively cheap. If one uses ClientConnectionPoolDataSource with the JDBC statement cache, the list of open statements can however be quite long, and lookupCursorActivation() needs to spend a fair amount of time iterating over the list and comparing strings.
> The time spent looking for duplicate names in lookupCursorActivation() is actually wasted time when it is called from the network server, since the network server assigns unique names to the statements it executes, even when there are duplicate names on the client. It would be good if we could reduce the cost of this operation, or perhaps eliminate it completely when the client doesn't use cursor names.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.