lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



I won't be the best responder, but you will get others.. :)

What I'd consider if I was you, is the syntactic simplicity (readability, maintainability) of the language you will choose. Partly, it is about execution speed, but if you choose something that later on just drools you down because of lack of expression, that's sacrificing developer resources. I'd _not_ roll my own language.

That said,
- try it. You didn't refer to the platform you're running on, which would be vital information to know whether "thousands" is applicable or not. It's definately not out of the reach (of a modern computer) anyways. On 20-200MHz embedded, it might be.

- memory. How much do you have it; can you have a pool of pre- initialized Lua states available, that you'd just grab and call per each invokation. alas:

- threading. Are the invocations coming sequentially (you'd need just one lua_State) or N numbers whenever?

- tradeoffs: nothing much. I don't see a single thing where modding Lua would make it essentially faster for you. Number types, if you're running without an FPU (surely, you aren't?).

- precompiling. You say configuration files, and talk of LuaJIT. If you can completely pre-do the compilation phase, you'd definately gain some speed. Question is, if you use the same script multiple times, precompile. If not..

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

How could they? Meaning yes, you can (should) disable things like 'os.*' table; simply set them to nil or better still never initialize in your host C module.

Then Lua will only be able to touch what your object bridging allows it. What exactly you mean by 'hurt'?

Eternal loops could be seen as a way to hurt; but there are ways to prevent that (timers, mainly).

- 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?

This escapes me; can you rephrase that (or maybe someone else gets it rights and teaches us).

Please tell the list where you ended up, and why. Would be interesting to hear! :)

-asko


Gabor Szokoli kirjoitti 13.10.2006 kello 20.16:

Hi there!

We are evaluating our options for a simple embedded language for our
configuration files. Our expectations for the language itself are
light: simple assigments and arithmetic on integers and strings,
if-then-else, loops, functions.
The requirements are strict for runtime performance, especially low
invocation overhead: thousands of short scripts will get invoked every
second!
We'll be injecting different c++ object instances (of the same type)
for the scripts to manipulate.
I have seen the abundance of tutorials and documents explaining how to
do this with lua, which is great. I'll read them all if you guys can
give promising answers to these questions:
- What can we expect in such "impulse" performance?
- 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.
- Would startup time benefit from using LuaJIT Ahead of Time compilation?
- Can I make sure no script can hurt the host process?
- 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?

Our current contenders for the role in order of preference:
Lua, "roll our own" (possibly with XIDEK), and Squirrel.
Let me know if you know of any other likely competitors :-)


Thanks for any advice:

Gabor Szokoli