How much more optimization is possible?

[oxysoft]

Hello! we have used MoonSharp extensively in our game and the poor performance are starting to catch up onto us. Calls like Script.DoString result in a long chain of statement objects that unfold recursively. It seems that each opcode and structural element is an object! Crazy! In WattleScript, I notice that the statement objects are still class, so I am wondering what is the work that has been done in optimization so far, and whether we can do more as well, and what are some of the limitations. The DynValue is a very convenient type used all over MoonSharp, and turning it into a struct seems like it would require a fundamental rewrite.
Cheers!

[CallumDev]

Hi,

The main optimizations applied on top of MoonSharp are:

• The DynValue to struct opt as you mentioned. In Unity in particular this increases speed at least 2x against MoonSharp.
• Instructions being encoded as tightly packed structs, instead of full classes. This is another massive increase performance-wise, particularly reducing the amount of objects the GC has to track.
• CallStackItem being turned into a struct, removing an allocation per method call: Refactor CallStackItem to struct #5
• ScriptExecutionContext being turned into a struct, removing an allocation per interop method call: https://github.com/WattleScript/wattlescript/pull/64/files
• Minor constant folding (original PR back before the opcode rewrite was here) Compiler: Evaluate constant expressions moonsharp-devs/moonsharp#290

As you've noticed, statement is still a class - but statement is part of the syntax tree used when compiling to opcodes. You have the option of dumping bytecode to a binary format used by wattle, which you can load at runtime without compiling the script again. This format is not stable, however, and it may be best for stability's sake to continue using DoString.

I would strongly recommend dropping in WattleScript and swapping your namespace references around to see the difference in performance and evaluate if that is enough for you. The low hanging fruit have pretty much all been picked, and further performance gains would probably come from rewriting the stack based bytecode compiler to be register based like Lua.