Errors when tracing LuLPeg

[pygy]

Hello, I get a slew of errors when I try to profile LuLPeg:

https://gist.github.com/pygy/b23ac1c81c6d3fffa387

Luatrace gets lost after 62 milliseconds, and the parsing itself takes 5+ secondson my machine.

Any suggestion?

[geoffleyland]

On 12/06/2013, at 6:06 AM, pygy [email protected] wrote:

Hello, I get a slew of errors when I try to profile LuLPeg:

https://gist.github.com/pygy/b23ac1c81c6d3fffa387

Luatrace gets lost after 62 milliseconds, and the parsing itself takes 5+ secondson my machine.

Any suggestion?

The first bunch of errors appear do be because you're executing code in a string (I think) and you can probably ignore them. The one that makes it crash, though, is more serious - it means it's lost track of the call stack at some stage. Tail calls and returns make this kind of tracing really difficult. I'm afraid I'm a bit busy at the moment, but I'll put trying luatrace with lulpeg on my todo list.

[pygy]

How about loadstring()ed code that returns functions? There are four instances of this in compiler.lua, here's the simplest:

compilers["char"] = function (pt, ccache)
    return load(([[
        local get_int = ...
        return function(subject, index, cap_acc, cap_i, state)
             -- dprint("Char    ",cap_acc, cap_acc and cap_acc.type or "'nil'", cap_i, index, state) --, subject)
            local c, nindex = get_int(subject, index)
            if c ~= __C0__ then
                return false, index, cap_i
            end
            return true, nindex, cap_i
        end]]):gsub("__C0__", tostring(pt.aux)))(get_int)
end

I know that in all cases, I could use a closure with upvalues instead of what I'm doing now, but I'll have to take the loadstring() road at some point, so I'm gently transitioning.

I'm also about to introduce tail calls in loadstring()ed code. I guess it does not bode well for profiling...

If you want to investigate the crash, the code in src must be run from that directory, while lulpeg.lua is a packed file that can be put anywhere.

~/tmp/mtytest.lua

local lulpeg = reqiuire(arg[1])

-- test code

then

.../LuLPeg/src$ lua -luatrace.profile ~/tmp/mytest.lua init

or

.../LuLPeg$ lua -luatrace.profile ~/tmp/mytest.lua lulpeg

to build lulpeg.lua, run ./scripts/make.sh from the LuLPeg directory.

[daurnimator]

I'll put trying luatrace with lulpeg on my todo list.

Any progress filing down that TODO list?

[geoffleyland]

On 13/03/2015, at 8:21 am, daurnimator [email protected] wrote:

I'll put trying luatrace with lulpeg on my todo list.

Any progress filing down that TODO list?

I’m afraid I haven’t looked at luatrace in a long time. The problem here is likely misidentification of tail calls or hidden yields or something, and the debug API is not quite precise enough to always get these right. Are you, then, using LuLPeg and suffering from performance problems?

[daurnimator]

Are you, then, using LuLPeg and suffering from performance problems?

One part of my application was using lulpeg, while another was having performance problems.