db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Lichtman <swa...@rcn.com>
Subject Re: Two poorly optimized functions in SQLParser.java
Date Mon, 27 Dec 2004 19:45:27 GMT

>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.

It's time for me to out myself. I wrote most of sqlgrammar.jj, along with a 
lot of the other Cloudscape/Derby language code. I no longer work on 
Cloudscape or Derby, but I'm still interested in it.

The code in SQLParser.java consists mostly of rules from sqlgrammar.jj and 
lookahead code. I suspect the massive nested if statements are for lookahead.

sqlgrammar.jj uses a single token of lookahead by default. The first 
implementation of sqlgrammar.jj used numeric lookahead to disambiguate the 
grammar. That is, where javacc would report that more tokens of lookahead 
were needed, I would put in LOOKAHEAD(2) (or 3 or 4, or whatever javacc 
suggested). This led to a very large parser.

The javacc development team told me that the size of the parser would be 
reduced significantly if, in those places where more than one token of 
lookahead is needed, we used semantic lookahead rather than numeric 
lookahead. What that means is that, where the grammar is ambiguous with a 
single token of lookahead, we use a hand-written method for lookahead 
rather than tell javacc to look ahead two or more tokens. When I made this 
change, the number of generated methods starting with "jj_" shrank 

I suspect the ugly massive nested if statements in SQLParser.java have to 
do with lookahead. I thought that maybe someone had put in some numeric 
lookahead, but I didn't find any such thing when I looked through 
sqlgrammar.jj. It's possible that I missed something, though.

In any case, it would help to have the complete call stack for the methods 
in question. I am particularly interested in which grammar rules are 
calling these methods. Given that, I might be able to figure out what's 
going on by looking at sqlgrammar.jj

                        -        Jeff Lichtman
                                 Check out Swazoo Koolak's Web Jukebox at

View raw message