Re: embedded lua: invocation overhead?

[Mike Pall <mikelu-0610@...>]

Hi,

Gabor Szokoli wrote:
> I am woried about vm startup.
> A single call can have about 5 independent script invocations at
> different stages of call processing, and we handle hundreds of calls
> each second.

Only hundreds? :-)

On a 3 GHz P4 a lua_call() to an empty Lua function takes around
80ns. A lua_pcall() (which is what you probably want) or a
lua_resume() takes around 130ns. Times are only slightly lower
with LuaJIT because the overhead of calling _into_ the VM is
pretty much constant.

So you can make around 8 million calls per second into Lua (minus
the time your app and the Lua functions take). Still worried?

[
Note that a Lua->C call takes 48ns with Lua and only 8ns with
LuaJIT. The comment about embedding vs. extending is right on
spot. But it seems extending is not suitable for your problem.
]

> >- threading. Are the invocations coming sequentially (you'd need just
> >one lua_State) or N numbers whenever?
> 
> Possibly as many as parell calls: indefinite.

Well, what's your concurrency model? N processes or N threads or
N multiplexed contexts (in one thread). The latter would be ideal
for Lua since you only need a single VM instance.

For N threads model: there is no locking in the Lua core by
default -- you can enable it, but it would reduce the performance
(and is not really concurrent). Instantiating multiple VMs is
another option, except that you need to load (and compile) the
scripts into all of them (or maybe on demand).

For the N processes model: not recommended and of course you'd
need different Lua VMs.

> Yes, the scripts would come from config files, practically never reloaded.
> They in fact constitute configuration of call handling.
> They just get run terribly often :-)

This is no problem for a JIT compiler, provided you use a single
VM instance. Compiled functions are cached. But compilation
cannot span VMs (neither JIT nor AOT). I wouldn't worry about
AOT, the JIT compiler is very fast (microseconds range).

> Well, that. Segfault my process, corrupt memory, etc.
> I'm glad I can't.

Sandboxing is one of the strengths of Lua.

> The above trigger, a separate c++ thread would need to be able to
> destroy a vm instance and regain its resources.

As long as it's not stuck in a C function you can set a hook,
raise an error and it will return from the lua_pcall().

Bye,
     Mike