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 java).
-dain
