Re: [Hsqldb-developers] Performance enhancement for com.org.hsqldb.Like.compareAt() method

[Fred T. <fr...@us...>]

Thanks Gary,

We don't have a LIKE test in the few tests we use for performance
regression (improvement) measurements.

The code has moved on a lot since the version you are using. The
current code is in the SVN repository (/base/trunk/). The
compareAt method hadn't change that much and I've just applied
and committed your suggestion.

The current code (for version 1.9) is fully multithreaded
(subject to data integrity considerations). I suggest you use SET
DATABASE TRANSACTION CONTROL MVLOCKS. I'd be please if you come
up with new suggestions for improvements.

One test you can run is org.hsqldb.test.TestBench. You can use
something like the following command line arguments
-driver  org.hsqldb.jdbcDriver -url
jdbc:hsqldb:mem:test;hsqldb.tx=mvlocks -user sa -init -clients 3
-tpc 20000

I don't know much about microcode execution, but used to code
M68000 assembly. I assume instance variables are in main memory,
the stack is probably in the cpu cache and the parameters may be
passed in registers (how many?) and variables may be
register-based. Vaguely correct?


Regards

Fred

On Thu, 13 Aug 2009 10:23 -0500, "Frost, Gary"
<Gar...@am...> wrote:

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: hsq...@li...
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 …


[1]http://hsqldb.cvs.sourceforge.net/viewvc/hsqldb/hsqldb/src/org
/hsqldb/Like.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 ki
nd of performance delta you observe.

Of course I would welcome comments/suggestions.

Gary

References

1. http://hsqldb.cvs.sourceforge.net/viewvc/hsqldb/hsqldb/src/org/hsqldb/Like.java?revision=1.4&view=markup