|
From: Fred T. <fr...@us...> - 2009-08-13 20:08:21
|
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 |