Re: embedded lua: invocation overhead?

[Nick Gammon <nick@...>]

On 14/10/2006, at 3:16 AM, Gabor Szokoli wrote:

> - What can we expect in such "impulse" performance?

I have done a small test using loadstring on a small in-memory script  
that does 3 assignments and creates a function.

On my moderately slow PC (it's a few years old) I could do over  
27,000 of those a second. That was both compiling into VM code, and  
running the resulting function. I didn't read files, as any thing you  
do that may require file reading would have that overhead anyway.

> - What are the things I can trade off for startup speed? I'm sure I
> won't need a garbage collector for example, no sustained script
> execution.

Are you creating new script spaces? If not you will eventually get  
garbage. If so, garbage collection won't be a big problem because the  
collector will have no real reason to start, for a small script.

> - Would startup time benefit from using LuaJIT Ahead of Time  
> compilation?

Possibly, although I think the LuaJIT documents only quote a modest  
improvement in execution time.

> - Can I make sure no script can hurt the host process?

If you run scripts the recommended way, the host process should not  
be hurt, excepting possibly running out of memory with a runaway  
script that created huge internal tables.

I have known the host to crash if you do something a bit silly like  
calling lua_checkstring outside a Lua "protected call" environment,  
because it tries to raise an error by doing a long jump, where there  
is no "handler". However if you code correctly I think you are pretty  
safe. I have quite a few users and I have never had reports, that I  
recall, that a Lua script crashed the application.

> - Can I destructively interrupt the "parse" (or whatever the
> equivalent of dofile is for an in-memory bytecode-compiled script
> which I am sure I can cache and reuse) function when a safety timer
> expires?

If you can parse a script in about 1/27000 of a second, I can't  
really think why you would want to do that. The execution part can be  
stopped by placing "hook" functions, which are tested on each VM  
instruction cycle. If you thought a script execution might go into an  
endless loop, then such a hook function could well be desirable.

- Nick