For an interpreted language Lua is performant as hell. I haven't looked at code here. Is the Lua code's host being kept alive or does everything start from scratch on each call? (I don't actually know, how much Lua state initialisation costs. Just guessing it could amount to something perceivable.)
On second thought, it should be quite a difference. Loading a Lua chunk cannot be done without handling lots of strings. For its execution many more strings than user data cannot be involved or Lua wouldn't be as fast as it is. Playing with strings is costly.
The language definition of Lua may sound like it's a scripting language, but its reference implementation is not - it wants you to believe that it is one. In reality it is closer related to Java, because it only executes bytecode, not scripts. The "interpreter" compiles everything into bytecode to be run onto an universal virtual machine instead of executing the Lua script directly. Most other scripting environments that allow bytecode (like Python) only offer it as an optional feature for more speed, but Lua only executes bytecode, just like Java.
Also Lua is a language definition not its implementation.
For reference PUC Lua is about 20 times slower as C.
Luajit is almost identical in speed to C, it can however analyse the code and could for example clean up loops during runtime.
@Letalis Sonus You're right. And if your point was that I might have brought my thoughts in better order and expressed myself more consise, you're correct, also. I'm hurting my head these days trying to get ros2 on fastdds to hand out message type information on request.
But I'm not wrong, am I. If the Lua binary gets started and the script loaded every iteration, that'd cost significantly more time than when keeping it up.
Makes me wonder if it actually implements caching for these sort of things. Testing it would be fairly easy: compile the script into pre-compiled bytecode and execute that instead and compare the results.