You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Tore Andre Olmheim (JIRA)" <de...@db.apache.org> on 2006/09/18 15:31:25 UTC
[jira] Commented: (DERBY-1862) Simple hash improves performance
[ 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