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 "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/09/22 19:05:23 UTC
[jira] Resolved: (DERBY-1862) Simple hash improves performance
[ http://issues.apache.org/jira/browse/DERBY-1862?page=all ]
Daniel John Debrunner resolved DERBY-1862.
------------------------------------------
Fix Version/s: 10.3.0.0
Resolution: Fixed
Assignee: Andreas Korneliussen
With a modified version of the simple performance test case in DERBY-1876 (ie. using column names) I saw a 35% performance improvement due to this fix. I will attached the modified test case to DERBY-1876 as it's interesting for that investigation as well.
Thanks very much for Tore Andre Olmheim for raising the issue and providing the insight into where the problem lay, and to Andreas Korneliussen for providing the patch.
> 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.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
>
> 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.
-
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