I would also add that app developers might be assuming that
the compiler does a lot of optimization, etc. PUC-Rio Lua does
not do any optimization.
This was an issue in my old project. The app team said that
the Lua version of their code ran 50-500x slower than C.
I spent about 2 days getting that to 5-10x slower. I just did
some basic optimizations that we all learned when we started
programming (back in the dark ages).
Did you make the optimizations in your code or in the Lua
interpreter?
I optimized the application, not Lua.
For example
- we changed global to locals.
- the original code had an if statement in a very large loop in a function. The if determined what processing was done & it didn’t change for any given invocation of the function:
Function x(flag)
Local I
For I=1,10000000 do
If Flag then
Process1
Else
Process2
End
End
End
We took the if out of the loop:
Function x(flag)
Local I
If flag then
For I=1,10000000 do
Process1
End
Else
For I=1,10000000
Process2
End
End
End
Modern optimizing compilers do this automatically for, eg, C.
Why not use LuaJIT? What do people think of LuaJIT on here? Are
there any cons to using LuaJIT, besides the extra space required?
LuaJIT wasn’t a viable choice at the time of this project.
It wasn’t supported and was compatible with an earlier version of Lua.
It makes use of highly tuned fragments of pre-made assembler. Also, IIRC, it would dynamically generate some assembly code. Neither of these were possible in our target environment.
These all were specific to our environment and customer — your situation may well be different
Frank Kastenholz