[antlr-interest] Performance and LA(int)

[Micheal J]

> > For C# code generation, LA(1) and LA(2) are cached in
> >*lexers*. This resulted in noticeably better performance. Our 
> >basic performance tests suggested that caching LA1/LA2 in 
> >parsers (in addition to lexer caching) didn't always result in 
> >better performance. Depends on the grammar it seems.
> >Weird or what?
> >
> >Micheal
> 
> 
> I was going to suggest that it's a shame LLkParser.LA() can't 
> be final/sealed
> - it only gets overriden by the debug parsers which doesn't 
> seem like a very good reason to slow down production code. 

We are in agreement here. IIRC, Kunle looked for opportunuties to eliminate
virtual methods on the critical path. Short of maintaining two
[nearly-]identical copies of the code (in release and debug classes - same
for lexer/tree-parsers), there didn't seem to be a way around this (and
others). Any ideas?

> Then I started actually reading the code and there's a heck 
> of a lot going on when you call LA() even if you only expect 
> to get the same result back each time. Really, final or 
> virtual, there's no chance of it getting inlined, lets put it 
> that way. The code was written by someone who loves OO 
> principles far more than performance.

You may be right but, how else would one be able to support some of the more
powerful features of ANTLR like lexer/parser multiplexing and composition?.

> I'm interested that you didn't always get a speedup in the 
> parser by caching the result of LA(). Still, I'd have left 
> the code in there - it's not going to do any harm either way.

It might _hurt_ performance. It did for some grammars in any case. 

We actually decided to wait for ANTLR3 to overhaul things. To that end, if
you or anyone else have good, strong ideas about what a blazingly fast
lexer, parser, tree walker/parser should look like, I'm all ears. All the
better if you can supply source code snippets/samples - which can use safe
and/or unsafe features.

Cheers,

Micheal