db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3882) Expensive cursor name lookup in network server
Date Tue, 22 Sep 2009 14:14:16 GMT

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

Bryan Pendleton commented on DERBY-3882:

> it needed on average ~30% shorter time


Is this because this particular benchmark has many open named statements
for the connection? I guess that if the connection has 50 open named statements,
we call String.equals on average 25 times to find the one we want? Does this
indicate that we ought to have a hash table here rather than a sequential lookup?

I'm a bit surprised that String.equals doesn't itself make this optimization. Is this
worth raising with the JDK itself?

Your optimization seems reasonable to me, though clearly we don't want to
go through this complexity for *every* call to String.equals, just the ones where
the performance win justifies it.

> 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, SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: check_hash.diff, Cursors.java
> 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.

View raw message