db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-212) Optimize some specific methods in Network Server to improve performance
Date Thu, 22 Dec 2005 17:31:32 GMT
     [ http://issues.apache.org/jira/browse/DERBY-212?page=all ]

Knut Anders Hatlen updated DERBY-212:

    Attachment: DERBY-212-parsePKGNAMCSN.diff

I have uploaded a patch (DERBY-212-parsePKGNAMCSN.diff) which changes
the following files:

M      java/drda/org/apache/derby/impl/drda/DDMWriter.java
A      java/drda/org/apache/derby/impl/drda/DRDAString.java
A      java/drda/org/apache/derby/impl/drda/Pkgnamcsn.java
M      java/drda/org/apache/derby/impl/drda/DRDAStatement.java
M      java/drda/org/apache/derby/impl/drda/Database.java
M      java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
M      java/drda/org/apache/derby/impl/drda/DDMReader.java

The patch only addresses the reported problems in
parsePKGNAMCSN(). This method parses a PKGNAMCSN object and returns a
string with all the fields concatenated. When other parts of the code
need one of the fields, a StringTokenizer has to be used to fetch the
field. This approach leads to a lot of unnecessary object allocation
and string parsing.

What the patch does is basically:

  1) Instead of returning a string from parsePKGNAMCSN(), an object of
     type Pkgnamcsn is returned. This object has accessor methods
     which are much cheaper than the methods in StringTokenizer.

  2) Since the strings read in parsePKGNAMCSN() often are repeated,
     reusing the strings seemed like a good idea. To achieve this, the
     class DRDAString was implemented. That class stores a byte array
     and can return the array as a string. Strings are cached to avoid
     allocation and decoding if the byte array has not
     changed. Pkgnamcsn objects are also cached, so a new one is only
     allocated when one of its fields has changed.

  3) In Database.java, a substring of the original PKGNAMCSN string
     was used as a hash key. With this patch, a new internal class
     StmtKey is added to Database. That class implements equals() and
     hashCode() in a way that enables its use as a hash key instead of
     the substring that was used originally. Caching is also
     implemented to avoid allocating new StmtKey objects when an old
     one can be reused.

Derbyall ran without errors.

I have also attached graphs showing the performance improvements. The
graphs show the throughput of 1-100 clients running read-only load
(select one row from a table which is in the page cache). The file
throughput.png shows the throughput as transactions per second with
and without the patch, and throughput-normalized.png shows the
increase in percent for different number of clients. The graphs
indicate a speedup of 5-8% with this particular load.

Could someone please review and comment on the patch?

> Optimize some specific methods in Network Server to improve performance
> -----------------------------------------------------------------------
>          Key: DERBY-212
>          URL: http://issues.apache.org/jira/browse/DERBY-212
>      Project: Derby
>         Type: Improvement
>   Components: Network Server, Performance
>     Versions:
>     Reporter: Kathey Marsden
>     Assignee: Knut Anders Hatlen
>     Priority: Minor
>  Attachments: DERBY-212-parsePKGNAMCSN.diff, throughput-normalized.png, throughput.png
> In reviewing the Network Server Code and profiling there were 
> several areas that showed potential for providing performance 
> improvement.
> Functions that need optimizing to prevent unneeded object 
> creation and excessive decoding
> parsePKGNAMCSN()
> parseSQLDTA_work()
> buildDB2CursorName()
> In DDMWriter and DDMReader, use System Routines in 
> java.util.Arrays and System.arrayCopy instead of 
> writing code to do functions like copy arrays and 
> pad strings.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message