db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1862) Simple hash improves performance
Date Wed, 20 Sep 2006 14:52:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1862?page=comments#action_12436251 ] 
Daniel John Debrunner commented on DERBY-1862:

The patch looks fine and I assume works correctly, but there is room for improvement, related
to performance:

- The map is always created, even if it is never used. This will increase memory usage and
slow down existing applications a little.

- The map is created and filled in for an individual ResultSet, but in fact it's a property
of the compiled plan, so ideally
there could be one copy of this map per compiled plan. So with a multi-user application running
the same statements this
patch will consume more memory as a factor of the number of users. Now there is probably other
meta-data aspects of
an EmbedResultSet that could be shared at a plan level, so this could be seen as future cleanup.

- Rather than using new Integer() as the values for the hash map, the code could use ReuseFactory.getInteger()
reduce memory usage.

I'm fine with the patch being committed, but would like to ensure these optimizations are
not lost.

> Simple hash improves performance
> --------------------------------
>                 Key: DERBY-1862
>                 URL: http://issues.apache.org/jira/browse/DERBY-1862
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance
>    Affects Versions:,
>         Environment: WinXp, JRE 1.5_6., Hibernate 3.1
>            Reporter: Tore Andre Olmheim
>         Attachments: DERBY-1696v2.diff, DERBY-1862.diff, DERBY-1862v2.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 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.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message