Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Errors when tracing LuLPeg #7

Open
pygy opened this Issue Jun 11, 2013 · 5 comments

Comments

Projects
None yet
3 participants

pygy commented Jun 11, 2013

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?

Owner

geoffleyland commented Jun 12, 2013

On 12/06/2013, at 6:06 AM, pygy notifications@github.com 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 commented Jun 12, 2013

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.

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

Any progress filing down that TODO list?

Owner

geoffleyland commented Mar 12, 2015

On 13/03/2015, at 8:21 am, daurnimator notifications@github.com 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?

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment