[antlr-interest] Performance and LA(int)

[John D. Mitchell]

>>>>> "Micheal" == Micheal J <open.zone at virgin.net> writes:
[...]

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

For Antlr v3, you can do the variants together as part of the
StringTemplates of the code generator -- via e.g., conditionals in the
templates and/or substitute templates.


[...]

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

Yep, it's not nearly as simplistic as people seem to think.

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

I'm not a C# guru so I'll refrain from making any specific comments on
that.

Algorithmically, the Antlr v3 obviates a lot of these kinds of "just making
sure" sillinesses.  Code generation-wise, the cleanliness of the model (so
far anyways :-) seems to make things pretty easy to change.  Part of that
is because there's a lot more focus on making code-gen support for a lot of
different languages easy/good/etc. (which definitely wasn't the case in
e.g. Antlr v2 and PCCTS).

In terms of the generated code itself, the needs of the Antlr model will
drive a lot of stuff but given the easy flexibility provided by the
StringTemplates, I think there's lots of room for experimenting with
different implementations.  For example, I'm particularly interested in
tweaks or outright different code generators targetting specific tradeoffs
(limited code & data space, etc.).

Have fun,
	John