db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tore Andre Olmheim (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1862) Simple hash improves performance
Date Mon, 18 Sep 2006 13:31:25 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1862?page=comments#action_12435473 ] 
            
Tore Andre Olmheim commented on DERBY-1862:
-------------------------------------------

Yes I agree with Andreas that my patch will leak memory.
In our system this method is mainly called from 
findColumnName(String columnName)  in org.apache.derby.impl.jdbc.EmbedResultSet.

This method is only comparing column-names, and there is a limited number of column-names
in a database
so the memory leak will not be a big issue.

But, of course if the SQLEqualsIgnoreCase is used by other classes, then Andreas has a good
point.
I still think my Hashtable version will be the fastest.

The best solution would be to refactor  findColumnName(String columnName)  in org.apache.derby.impl.jdbc.EmbedResultSet.

I will leave it to the persons,  who knows the derby design well, to decide what approach
to take.
 


 

> 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: 10.1.3.1, 10.1.2.1
>         Environment: WinXp, JRE 1.5_6., Hibernate 3.1
>            Reporter: Tore Andre Olmheim
>         Attachments: DERBY-1862.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.
-
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

        

Mime
View raw message