db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RPost" <rp0...@pacbell.net>
Subject Re: Two poorly optimized functions in SQLParser.java
Date Mon, 27 Dec 2004 21:14:38 GMT
Now your the one that's kidding right?

You gave a great answer. Too bad it wasn't related to the question.

Which was:

> Does anyone have any experience or knowledge about the JavaCC process
> used to produce SQLParser.java?

I will assume your answer to that one is 'no'.

I'm trying to determine why JavaCC is spitting out code with 115 and 200
nested IFs rather than the (much) more efficient SWITCH statement it puts
out for most of the other code performing similar functionality.

I have generally found in the past that 115 executions of a function takes
longer than one execution-:)

----- Original Message ----- 
From: "Dain Sundstrom" <dsundstrom@gluecode.com>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Monday, December 27, 2004 11:41 AM
Subject: Re: Two poorly optimized functions in SQLParser.java

> 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

View raw message