Performance: Cache compiled mods and in-game scripts
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?
I have the same bug
Hello, Viktor,
thanks for letting us know. This issue was reported internally.
Kind Regards
Keen Software House: QA Department
Hello, Viktor,
thanks for letting us know. This issue was reported internally.
Kind Regards
Keen Software House: QA Department
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?
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?
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?
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?
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.
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.
Any movement on this? I’ve recently begun printing grids with PBs and was shocked to see that the compiled code was not cached. It causes unnecessary sim speed reduction on the server.
Any movement on this? I’ve recently begun printing grids with PBs and was shocked to see that the compiled code was not cached. It causes unnecessary sim speed reduction on the server.
Replies have been locked on this page!