[antlr-interest] Exception tests eat performance?

[Terence Parr]

Hi gang, my only additional comment would be that using return values 
makes it pretty hard to have other return values from a rule, which are 
arguably very handy.

Note that antlr does a simple static k lookahead test before resorting 
to backtracking in the generated parser.

Further, the use of boatloads of syn preds is not usually necessary and 
are used as a crutch too often.  At least they are there though ;)

Ter

On Wednesday, January 7, 2004, at 08:54  AM, Karl Meissner wrote:

>
> It seems that antlr uses exceptions in a lot of the generated parsers 
> where simple test will do.
> Everything that I have read is that an exceptions have a very high 
> overhead and it is undesirable
> to  generate them in a tight loop where they happen a lot.
>
> Exceptions are used so extensivly it would require a big rewrite to 
> change but I wanted to
> raise it as an issue
>
> A very common piece of code in a parser is
>
> try {
>   {
>     match( SYM1 );
>     match( SYM2 );
>     match( SYM3 );
>  }
> } catch (RecognitionException)	{
>   synPredMatched84 = false;
> }
>
> where match throws an exception if the next token is not the parameter.
> Since match is just
> public virtual void  match(int t)
> {
>     if (LA(1) != t)
> 	throw new MismatchedTokenException(tokenNames, LT(1), t, false, 
> getFilename());
>     else
> 	consume();
> }
>
>
> Using if based tests would be faster I think...
>
> Something like this
>
> bool Rule10() {
>   if( !Rule22() ) goto 	_RecognitionException_123:
>
>   currentSym = SYM1; if ( LA( 1 ) != currentSym ) goto 
> _RecognitionException_123; consume();
>   currentSym = SYM2; if ( LA( 1 ) != currentSym ) goto 
> _RecognitionException_123; consume();
>   currentSym = SYM3; if ( LA( 1 ) != currentSym ) goto 
> _RecognitionException_123; consume();
>
>   return true;
>
>   _RecognitionException_123:
>     if (0 == inputState.guessing)
>     {
>       reportError(currentSym);
>       consume();
>       consumeUntil(tokenSet_27_);
>
>       return true;  //attempt to recover in the calling rule
>     }
>     else //guessing
>     {
> 	return false;
>     }
>   }
>
> I probably missed some the the code paths with predicate guessing and 
> error handling but
> I still think you can get the same behavior as the exception with a 
> combination of if, goto and
> storing information into stack.
>
> And get a performance improvement....
>
> Karl
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/antlr-interest/
>
> To unsubscribe from this group, send an email to:
>  antlr-interest-unsubscribe at yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/
>
>
>
--
Professor Comp. Sci., University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Co-founder, http://www.jguru.com
Co-founder, http://www.knowspam.net enjoy email again!
Co-founder, http://www.peerscope.com link sharing, pure-n-simple




 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/antlr-interest/

To unsubscribe from this group, send an email to:
 antlr-interest-unsubscribe at yahoogroups.com

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/