Re: LPeg pattern optimization

[Ico <lua@...>]

* On 2010-02-20 Fabio Mascarenhas <mascarenhas@acm.org> wrote  :

> When using locals you are effectively inlining the pattern for each of
> your lexical elements (terminals) inside the grammar definitions, so
> if you define your number terminal in a local and use it three times
> in your grammar then the resulting grammar will have three copies of
> the pattern for numbers.
> 
> When you moved the terminals to non-terminals inside the grammar you
> replaced the inlined copies with plain LPEG CALLs. Continuing the
> previous example, now you only have one copy of the pattern for
> numbers in your grammar, and three calls to it in the non-terminals
> that use it.

Yes, I was able to deduce this from the pattern:print() output after I
posted my question, so this seems to make sense indeed. I guess there
are good reasons for inlining rules which are not part of a grammar, so
I'll just keep this in mind when writing parsers.

> About whether is this a best practice, it depends on what you are
> gaining in terms of size, as inlining patterns lets LPEG do other
> kinds of optimization that will speed up the actual parsing, while the
> final size of the grammar is generally unrelated to the parsing time.

I noticed: my grammar is now only 15% of it's originial size, but the
speed is about the same.

> There also other considerations, such as that keeping everything in
> the grammar lets you easily change the definition of a terminal and
> compile a slightly different grammar, which is impossible to do if the
> terminal was defined in a local, as the original definition is baked
> in the grammar rules that use it.

Clear.

So it mostly boils down to 'it depends'. No problem, but it's good to
get to know the tools better to get the most out of it.

Thanks for your explanation,

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C