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:26:49 GMT
Thanks Jeffrey. That's the info I was looking for.

I will supply a call stack from Derby. I will also try to find the spot in
JavaCC that is spitting out the JJ_3R_315 method to see what part of
sqlgrammer.jj it is interpreting.

----- Original Message ----- 
From: "Jeffrey Lichtman" <swazoo@rcn.com>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Monday, December 27, 2004 11:45 AM
Subject: Re: Two poorly optimized functions in SQLParser.java

> >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
> 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
> 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
> significantly.
> 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
>                                  swazoo@rcn.com
>                                  Check out Swazoo Koolak's Web Jukebox at
>                                  http://swazoo.com/

View raw message