LuaJit will only make noticeable speed improvements if your mod executes pages and pages of Lua frequently - eg for total conversion mods.
Of course : the improvements from luaJit will be significant only if the slow down from the mod was significant in the first place. But I wonder whether there are really such mods. Unless someone writes his own pathfinding or other computationally intensive tasks. Pazyryk reports a high but says that he has a lot of room for improvements.
The other is that I don't quite understand how LuaJit would save time during game run, as opposed to only at game init. From a very cursory look, my understanding (probably incorrect) is that it is just giving you pre-compiled Lua. If so, then won't it only save you time during game init and not per turn? Can someone please tell me where I'm misunderstanding?
A standard interpreter parses the file then builds a bytecode representation: typically you have opcodes ("add", "read index", "push", "invoke", etc) acting on an value stack ("add" pops the two topmost values and push one). On execution, the VM looks for the next opcode, performs the operation, then look at the next opcode, performs the operation, etc. It is like emulating a CPU (although the image is wrong in many places).
A jit compiler, however, transforms the bytecode stream into a x86 stream similar to the program's stream itself. That way you get rid of the CPU emulation and directly run the code on the CPU like any program. So it adds a lag the first time a function is ran (since the bytecode needs to be compiled) but subsequent calls are faster. The JIT introduces a latency at startup but is faster after that.
Finally, the CPU emulation image is mostly wrong because a CPU model and a VM model are very different:
* The x86 instructions acts on registers while the bytecodes act on a value stack.
* The x86 instructions only handles numeric values while the bytecodes act on complex values (objects, strings, etc) and include high-level operations such as member accesses.
