Performance: Cache compiled mods and in-game scripts

Guest shared this bug 2 years ago
Reported

Game version: 1.200.030

Observation: Compiled mods and in-game scripts are not cached on disk.

It can be done relatively easily in MyScriptCompiler.Compile.

Technical

Working implementation as a Harmony patch

Please see files: MyScriptCompiler*.*

I'm pretty sure it is unreadable due to having to runtime patch an async method, but you get the idea for sure.

Compiling mods needs a bit more attention, because they need to register themselves. There is a Mod ID and some related administration. To be honest MyModWatchdog.AllocateModId is a quite unpleasant, non-deterministic solution. It almost prevented my caching attempt.

The Mod ID is used in some performance profiling injection as well (PerfCountingRewriter), which I had to disable to stabilize the compiled code. It could be fixed by storing a unique Mod ID in the cache, so they can be recalled. (I did not implement it this way, so careful!)

Test results

Single player world with 36 mods (with code) and 33 distinct in-game scripts loads ~33% faster.

World from a large multiplayer server (~500 grids) loads 18 seconds faster (original is 105 seconds).

Notes on the Dedicated Server

The Dedicated Server loads plugins too late, so I could no apply caching during world loading there. Please load plugins first, then mods and finally the world entities. It would allow fixing stuff there. It works with the client where plugins loaded quite early. Why shouldn't it work with the DS?

Replies (4)

photo
1

Hello, Viktor,

thanks for letting us know. This issue was reported internally.

Kind Regards

Keen Software House: QA Department

photo
1

I hope you ported the solution from my plugin (or created your own), because this performance fix is a huge one for people using a lot of mods and/or PBs.


Have you fixed the Dedicated Server's load order?

photo
1

Not in the Automaton Beta release? Why?


It is very simple and helps a lot with loading times, also helps with PB compilations during game.


My solution has been tested extensively by hundreds of players and on many multiplayer servers (Torch, because DS loads the plugins too late).


Any questions? Do you need help porting this to the game? What's the problem?

photo
1

How about looking up the PB cache based on a hash of the code, so new blocks spin up faster, and multiple blocks share the same code, giving the JIT more complete data to work with? I'm hoping/assuming that the final .dll isn't specialized for that specific block.

Leave a Comment
 
Attach a file