Re: Profiling LPEG

[Sean Conner <sean@...>]

It was thus said that the Great Roberto Ierusalimschy once stated:
> >   Okay, one thing I did was recompile LPEG to activate the ptree() function,
> > and dump both the 're' compiled version any my LPEG version.  The output was
> > very surprising.
> > 
> > 	're' version [1]:   3,212 lines long
> > 	'lpeg' version:   611,931 lines long
> > 
> >   It appers that 're' does a better job of generating LPEG than I did by
> > hand.  I'm surprised that the 'lpeg' version was only twice as slow, given
> > the results.
> 
> Without seeing your code, one thing popped in my head: In re, the only
> way to name a pattern is as a rule in a grammar. In LPeg, we can
> name patterns as grammar rules or as Lua variables. When you
> use a pattern inside another pattern, Lua expands its code, as if it
> was a macro. So, if you have patterns that appear multiple times inside
> others, and then those patterns are used inside other ones, etc., things
> can get very large.

  As I'm seeing.  I reworked another module from LPEG to re, and as a
result, the re one was a third the size.

> Quick comparison:
> -----------------------------------------------------------
> local P = lpeg.P"hello world"    -- pattern in a Lua variable
> (P * P * P):ptree()
> -- tree has 66 lines
> 
> local P = lpeg.V"P"         -- pattern in a grammar rule
> lpeg.P{P * P * P, P = lpeg.P"hello world"}:ptree()
> -- tree has 32 lines
> -----------------------------------------------------------

  I see.  Although, when I tried the above as-is, I got:

lua: ll.lua:3: attempt to perform arithmetic on a nil value (global 'P')
stack traceback:
	ll.lua:3: in main chunk
	[C]: in ?

(line 3 is "(P * P * P):ptree()).  The second chunk is fine.  Just an FYI
(Lua 5.4.4, LPEG 1.0.2 compiled with LPEG_DEBUG).

  Thanks for the confirmation.  I'm going to have to rethink my approach.

  -spc