Re: Debugging luacode => efficient file name retrieval?

[Eike Decker <eike@...>]

Hi Mike 

> I'm pretty sure this is fast enough and won't slow things down
> that much. Just be very careful what you request with
> lua_getinfo().

The bottleneck is mainly really the const char* => luastring conversion. Once
bypassed, it works fast enough - I changed the sethook method so I get only
hookcalls inside of lua if the file was changed. I am not sure if a function <>
filename lookup table would be quicker, since I am only pushing an original
luastring on the stack that can be retrieved quite easily - without any table
lookup which would require clock cycles as well.

> 
> > The table approach is also quite slow if the function is created by
> > an closure [...]
> 
> Well, only if you are creating (and calling!) closures at an
> excessively high rate. In this case: don't do it, it's slow even
> without debugging. ;-)

I already replaced the occurences because I realized that its not such a good
idea anyway. ;) 

> > In between I thought about this: How complicated would it be and how much
> > performance would it drain to mask the compiled bytecode?
> 
> You could add a new VM breakpoint instruction. Replace any
> regular instruction with it and store the original away. When the
> breakpoint is executed, activate the hooks, replace the
> instruction with the original (you can use the Bx operand for
> indexing an internal array), decrement the PC and continue with
> the VM loop.

Good to know - and yes ... too much work and not enough time right now. Though I
would be interested how it would work.

> 
> You'd need to be careful with string.dump(), though (if you use
> it). Other than that, I don't see a problem.
> 
> > And what would I need to consider for luajit? 
> 
> Well ... that's a different story. First you need to enable
> debugging. This disables many optimizations and adds lots of
> inline code for calling the hooks. Expect a serious slowdown.

I also changed the luajitdebug level, but since the engine core is already doing
the most expensive stuff, we didn't gain too much performance with using jit
anyway - coco is way more useful to us right now.

> 
> And then ... of course the bytecode swapping trick doesn't work
> here. Modifying the machine code on-the-fly is very tricky. Not
> for the faint of heart.

.. so I better don't touch it...

> 
> > It would be really great if I could implement the debugger in a
> > way that needs no additional resources...
> 
> Zero cost debugging is doable, sure. But it takes lots of work.
> I suggest you try to implement my earlier proposal first. ;-)

yep, I agree. It works now and is reasonable fast (though it slows down in bad
cases still at 1:~6, but 20fps instead of 120 fps are ok in that case...). I am
also using a few caches to solve some name lookups. We still need to test it if
it really works stable so far. Zero costs would be great... maybe this issue
could be considered for a future development of debug tools for Lua?

Thanks for your help!

Eike