db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: derby performance on java 6 for linux
Date Fri, 09 Nov 2007 10:24:16 GMT
Dion McMurtrie <dion.mcmurtrie@nehta.gov.au> 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

Mime
View raw message