[antlr-interest] Performance and LA(int)
John D. Mitchell
johnm-antlr at non.net
Thu Feb 24 08:50:09 PST 2005
>>>>> "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
More information about the antlr-interest
mailing list