Weaver

Summary

Weaver is a mod that roughly triples the performance of DSP. The mod does not alter gameplay, does not disable achievements and can be enabled/disabled anytime.

In my tests of late game saves, Weaver improves the game's performance by roughly 3.0-3.5x.

You'll experience the best performance while flying in outer space. You can read why in the _How it works_ section.

Mod compatibility

Known compatible mods:

• SphereOpt
• DSPOptimizations
• GalacticScale

Known incompatible mods:

• SampleAndHoldSim
• GenesisBook
• Multfuntion mod
• More Mega Structures
• VeinityProject
• PlanetMiner
• SmartTank
• PlanetwideSpray

Known issues

None. You can report bugs here.

How it works

The general idea is to avoid doing work that isn't necessary. The game spends a lot of time updating, for example, animation data on planets the player isn't on.

The mod solves this issue by "optimizing" planets the player isn't currently on. Whenever a player flies to a planet, the planet's logic is restored to the game's default logic to ensure

all animation and UI logic functions as expected. Anything being built, upgraded or destroyed on a planet will also, briefly, cause the planet's logic to revert to the game's slower logic.

Whenever a research completes, the mod will reoptimize all planets one at a time to ensure the optimized planet includes any stat changes from the research.

Could DSP developers implement these optimizations?

Spray coaters and statistics

Parallelizing spray coaters is relatively straightforward and provides a significant performance improvement in most saves.

Data layout

The general implementation of DSP is quite well thought out. The use of structs of entities makes the code already quite optimized.

The biggest performance problem is that the structs are too large. Even if a sorter is on the other side of the star cluster, the sorter's animation-relevant data still has to be loaded in when the game updates the sorter.

A lot of the optimizations in this mod could be implemented by the DSP developers by making even more use of struct-of-arrays design. That's what this mod uses to reduce memory bandwidth requirements and improve cache hit rates.

The large structs the game uses contains a lot of internal padding between its fields. Adding the attribute [StructLayout(LayoutKind.Sequential, Pack=1)] to each of the game's large structs should improve performance and reduce memory usage by removing padding in the structs. For some structs this can halve their size.

Assembler/Labs linear data access

Each assembler and lab contains multiple small arrays for things their recipe requires, how much it requires, what it produces etc. Access to all these smaller arrays, acrosds multiple assembler/labs, can effectively be seen as random data access. Although the arrays within a single assembler are allocation close to each other time wise, they are so small that they fill in the gaps between other allocations. This causes big issues because there is so many of these smaller arrays and they are accessed so often. To improve data access, Weaver has flattened these small arrays into one array. This improves data access as the data access pattern becomes fully sequential. Flattening the arrays also improves data access for sorters because their mostly sequential access to assemblers and labs means mostly sequential access to their flattened data.

Belt linear data access

DSP splits belts on a planet up into three parts: The individual belts, cargo paths and a cargo container. Each belt represents a belt on a single tile. A cargo path represents the path items moves on connected belts, this is what is responsible for actually moving items on the belts. Each planet has a single cargo container that stores all information about items on belts for that planet. This is presumably an optimization the devs have made to improve rendering performance. Cargo paths do not store the items themselves, instead they store an index to the items location in the