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" <[EMAIL PROTECTED]> To: "Derby Development" <[email protected]> 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 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 > 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 > [EMAIL PROTECTED] > Check out Swazoo Koolak's Web Jukebox at > http://swazoo.com/ >
