db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Two poorly optimized functions in SQLParser.java
Date Mon, 27 Dec 2004 19:41:16 GMT
On Dec 27, 2004, at 11:13 AM, RPost wrote:

> I don't see how the presence or absence of a JIT compiler is relevant.

Your kidding, right?  If not, please take some time to look at VM 
benchmarks over the last few years.  It shows that JITs have added 
several orders of magnitude to the performance of Java.

> These extremely nested 'if' statements are part of source code
> (SQLParser.java) that is being produced by JavaCC. The source file is 
> then
> compiled during build to a class file.

If you can convert it into a switch statement, so can the JIT compiler.

> Depending on the JVM being used at run-time there may not even be a JIT
> compiler.

Every major VM has a JIT compiler, so there we should play to them.  If 
the vm doesn't have a jit, you have much bigger issues.

> The decompiled class file, produced by either Sun's provided 'javac' or
> Jikes, also shows a nested if with a separate function call as shown 
> in the
> source code.
> I am merely suggesting that it would be more efficient if JavaCC 
> produced
> 'switch' statements for these rather than the nested 'if' statements.
> So far, I haven't been able to determine how to modify the 
> sqlgrammar.jj
> file to achieve this.

Seriously, if you believe that this is a real problem with performance, 
prove it.  This is a policy we have had in the geronimo project since 
the beginning.  There have been several times where people believed 
that certain code was slow, tried to prove it, and it turned out it was 
another chunk of code.  Also, without data you don't know if your 
solution is optional (or possibly worse).  Anyways, I suggest you time 
the code in isolation as it stands, and then hand modify the generated 
code as you describe above and time it again.

IMNOHO, only if it is a true provable performance problem should the 
code be changed to address the problem.  This is because normally 
addressing such issues introduces complexity, and this complexity adds 
a tax to all future development.  Also, complex code is more difficult 
for a JIT to understand so it can cut you off from future innovation in 
JIT technology (ask that guys that wrote the first XML parsers in 


View raw message