Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1387987349.1246285907684.JavaMail.jira@brutus>
Date: Mon, 29 Jun 2009 07:31:47 -0700 (PDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1862) Simple hash improves performance
In-Reply-To: <7336583.1158568102274.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-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-1862:
---------------------------------

    Derby Categories: [Performance]

> Simple hash improves performance
> --------------------------------
>
>                 Key: DERBY-1862
>                 URL: https://issues.apache.org/jira/browse/DERBY-1862
>             Project: Derby
>          Issue Type: Improvement
>    Affects Versions: 10.1.2.1, 10.1.3.1
>         Environment: WinXp, JRE 1.5_6., Hibernate 3.1
>            Reporter: Tore Andre Olmheim
>            Assignee: Andreas Korneliussen
>             Fix For: 10.2.1.6, 10.2.2.0, 10.3.1.4
>
>         Attachments: DERBY-1696v2.diff, DERBY-1862.diff, DERBY-1862v2.diff, DERBY-1862v3.diff
>
>
> We are currently developing a system where we load between 1000 and 5000 objects in one go. The user can load different chunks of objects at any time as he/she is navigating. 
> The system consist of a java application which accesses derby via hibernate.
> During profiling we discovered that the org.apache.derby.iapi.util.StringUtil is the biggest bottleneck in the system.
> The method SQLEqualsIgnoreCase(String s1, String s2) is doing upperCase on both s1 and s2, all the time.
> By putting the uppcase value into a Hashtable and using the input-string as key we increates the performance with about 40%. 
> Our test-users report that the system now seems to run at  "double speed". 
> The class calling the StringUtil.SQLEqualsIgnoreCase in this case is
> org.apache.derby.impl.jdbc.EmbedResultSet
> This class should also be checked as it seems to do a lot of looping.  
> It might be a canditate for hashing, as it is stated in the code:
> "// REVISIT: we might want to cache our own info..."
> Here is a diff agains the 10.1.3.1 source for org.apache.derby.iapi.util.StringUtil
> 22a23
> > import java.util.Hashtable;
> 319c320,326
> < 			return s1.toUpperCase(Locale.ENGLISH).equals(s2.toUpperCase(Locale.ENGLISH));
> ---
> >       {
> >          String s1Up = (String) uppercaseMap.get(s1);
> >          if (s1Up == null)
> >          {
> >             s1Up = s1.toUpperCase(Locale.ENGLISH);
> >             uppercaseMap.put(s1,s1Up);
> >          }
> 320a328,332
> >          String s2Up = (String) uppercaseMap.get(s2);
> >          if (s2Up == null)
> >          {
> >             s2Up = s2.toUpperCase(Locale.ENGLISH);
> >             uppercaseMap.put(s2,s2Up);
> 321a334
> >          return s1Up.equals(s2Up);
> 322a336,339
> >          //return s1.toUpperCase(Locale.ENGLISH).equals(s2.toUpperCase(Locale.ENGLISH));
> >       }
> >    }
> >    private static Hashtable uppercaseMap = new Hashtable();

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