Sorry about the clipped subject line. I hit send in error.
My subject should have been
'Performance enhancement for com.org.hsqldb.Like.compareAt() method'
....
________________________________
From: Frost, Gary
Sent: Thursday, August 13, 2009 10:11 AM
To: hsqldb-developers@lists.sourceforge.net
Subject: [Hsqldb-developers] Performance enhancement for com.
I was profiling some code which is using HSQLDB (I profiled with
oprofile on Linux) and discovered (looking at the generated x64 code)
that the org.hsqldb.Like.compareAt() method was consuming a lot of CPU
cycles.
So referring to ...
http://hsqldb.cvs.sourceforge.net/viewvc/hsqldb/hsqldb/src/org/hsqldb/Li
ke.java?revision=1.4&view=markup
Even though compareAt() is a clean recursive solution to wildcard
matching, unfortunately some recursive patterns don't get optimized
particularly well by the JIT. In this case the code is recursive and is
accessing fields of the instance and (as we may know) field accesses are
slower than stack access.
I may try and refactor to use a non recursive solution (and avoiding
field accesses), however my first experiment yielded a 10% improvement
on the application I was using, so I figured I would pass it along as a
suggestion.
If we wide the compareAt() API so that instance fields are passed as
arguments, the JIT optimizer is likely to assign the array references to
registers, which can then be kept in registers throughout the call
sequence. As the fields are never modified, and the JVM avoids having to
keep accessing memory we yields an improvement in performance.
Especially as the code recurses deeper into the match.
So my suggested change is to change
private boolean compareAt(String s, int i, int j, int jLen)
to
private boolean compareAt(String s, int i, int j, int jLen, char
cLike[], int[] iType)
and then to widen the call site (in compare(String)) from
return compareAt(s, 0, 0, s.length());
to
return compareAt(s, 0, 0, s.length(), cLike, iType);
Note that the code mody of compareLike is not changed (we are relying on
the fact that the stack version of clike and iType are hiding the fields
(I was too lazy to rename everything).
One some local microbenchmarks on a 24 core machine (it's nice working
at AMD ;) ) I have observed 57% improvement using this code
transformation. On my laptop I see a few %, but of course every little
bit helps.
If you guys have a performance benchmark/regression suite that you use
to measure performance regressions I would be interested in hearing what
kind of performance delta you observe.
Of course I would welcome comments/suggestions.
Gary
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
hsqldb-developers mailing list
hsqldb-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
