Dion McMurtrie <[EMAIL PROTECTED]> writes: > I've experienced a recent serious (factor of 6 or more) performance > degradation using derby 10.3.1.4 after upgrading to Java 6 (update 3) - > i.e. it was 6 times faster using Java 5 than Java 6. > > The results running my process on Windows using Java 5 or Java 6 are > similar to the result using Java 5 on Linux, however Java 6 is many > times slower. I've tried this on a number of Linux machines with the > same results - FC7, SUSE 10.1, CentOS 4 > > The process I am running is essentially running > org.apache.derby.tools.ij.runScript(java.sql.Connection, > java.io.InputStream, java.lang.String, java.io.OutputStream, > java.lang.String) > > a number of times with different SQL scripts. Each invocation of this > method takes significantly longer on Linux with Java 6. > > Is anyone aware of this issue? Is there a resolution?
Hi Dion, You've probably come across this bug in Java 6: http://bugs.sun.com/view_bug.do?bug_id=6471009 The problem occurs if you perform a lot of statement compiling, which I suppose is what happens in your test since you're running SQL scripts[1]. Derby generates java byte code on the fly when it compiles an SQL statement and loads the generated byte code with a class loader. Unfortunately, Java 6 has a performance regression in this area, so that class loading becomes expensive after a while. An application that prepares its statements once and executes them many times should normally not see this problem. Note that the bug report mentions using the client VM as a workaround. That's probably why you don't see it on Windows, since the client VM is used by default on Windows, I think. HTH, Footnotes: [1] It is possible to use compile-once-execute-many-times with ij.runScript() as well, and if your application depends on script execution performance, I would recommend it regardless of the JVM bug. Please see http://db.apache.org/derby/docs/10.3/tools/rtoolsijcomref30679.html for details. -- Knut Anders
