|
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