Re: Debugging luacode => efficient file name retrieval?

[Eike Decker <eike@...>]

> 
> My 2 cents. Given what was written in Lua's manual.html, I'd 
> question whether your app should be using those debug functions so 
> extensively in the first place, especially for the kind of app 
> you're running. I thought those functions are used sparingly, say 
> in a gdb-like setting, but they are not for running full-bore 
> providing a program trace. Don't call or hook anything unless you 
> absolutely need it.

Well, but how else could I write a debugger that allows setting breakpoints in
lua files? I don't see another solution then switching on the hook function...
I really need that feature. 
Of course, the user could write a function call where he likes to have a
breakpoint set - or I could parse the files before calling and insert my
breakpoint checks inside the code. I could overload the loading functions
dofile/require etc. and let them modify the luasourcecode to inject the
required break calls. But then I couldn't set breakpoints during runtime, or
could I manipulate the bytecode of the loaded function chunks somehow to
include certain calls or not? Or can I replace the bytecode of an function with
anotherone, if required?

> I hope you're not putting effort optimizing the wrong things...

Well, one thing was to put the filename of function on the luastack without
letting the Luaapi calculating the hash and so on:

//lua_pushstring(L,getstr(cl->l.p->source)); // not this
lua_lock(L); // instead this (from lua_pushstring and other functions)
luaC_checkGC(L);
setsvalue2s(L, L->top, cl->l.p->source);
api_incr_top(L);
lua_unlock(L); 

This change had a huge impact on the performance... I think if the debug.getinfo
function would push their strings (which are already hashed) without using
lua_pushstring on the stack, the performance would be much better.

However, performance still goes down if the current file has a breakpoint set,
since I have to check every line then that is executed. That is still pretty
bad. Only thing that I can currently think of here, is to check the range of
the function's definition before switching the hook to line callback mode. 

Eike