Re: Debugging luacode => efficient file name retrieval?

[Eike Decker <eike@...>]

Hi Mike


> Use the function object as a key for a weak keyed table which
> stores whether this is a function which has a breakpoint set. If
> the entry is nil, then lookup the file name and line number range
> info (the expensive calls to lua_getinfo()). If it's a target
> function, store true, else store false (negative caching). Now,
> you have a cheap way to check whether you are entering a function
> which has a breakpoint set.

During development I tried it out, but it was still not satisfying :/ - but
maybe I will try it again - my current approach is somehow not working
properly. The table approach is also quite slow if the function is created by
an closure i.e, 

function foo() return function () dostuff() end end 

foo() returns always different functions thus will always require the sourcefile
lookup. Its not very common, but the debug.getinfo function is really slow. I
can speed it up by bypassing lua_pushstring - the strings on name and source
are already lua-compatible strings (TString I think), so it is not required to
calculate everything again (which is done in lua at the moment). The hashing of
the string is taking about 80% of the execution time I think, so this improves
speed a lot to avoid this - maybe I will just overload debug.getinfo to respect
this...

== Different Idea:
In between I thought about this: How complicated would it be and how much
performance would it drain to mask the compiled bytecode? Setting a bit would
mark that this command should call the hook function. This would be really
usefull - the bits could be activated and deactivated with a special function.
It would allow full support for line/file breakpoints without too much overhead
I think.  

Is it hard to tune the vm interpreter of lua that way? And what would I need to
consider for luajit? 

It would be really great if I could implement the debugger in a way that needs
no additional resources...

Eike