db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DERBY-1862) Simple hash improves performance
Date Wed, 23 May 2007 01:21:16 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Myrna van Lunteren closed DERBY-1862.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 10.2.1.6
                   10.2.2.0

Closing issue altogether after adjusting fix version

> Simple hash improves performance
> --------------------------------
>
>                 Key: DERBY-1862
>                 URL: https://issues.apache.org/jira/browse/DERBY-1862
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance
>    Affects Versions: 10.1.2.1, 10.1.3.1
>         Environment: WinXp, JRE 1.5_6., Hibernate 3.1
>            Reporter: Tore Andre Olmheim
>         Assigned To: Andreas Korneliussen
>             Fix For: 10.3.0.0, 10.2.2.0, 10.2.1.6
>
>         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.


Mime
View raw message