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 cargo container. Cargo paths move this index around instead of moving the item itself.

Each index takes up 28bits of space. Storing an items id, stack size and proliferation only needs 24bits of space. Weaver removes usage on the cargo container and instead stores each items data in the cargo path in place of the index. The improvement here is removing the indirection to get an items data. This improves sorter update performance but slightly decreases belt buldings update performance. Data access time is improved but it's slightly more expensive to update an items data because of how it's stored in the cargo path.

Deduplicating data

Additionally, a lot of the information in each struct is duplicate constant values stored in each struct instance. For example, this includes recipe requirements and entity tier data. This can easily be moved to a separate array of structs that can be referenced, just like how this mod does it for assembler recipe information. This type of optimization can (so far from what I've seen) be applied to the following components: assemblers, inserters, labs, consumers, AnimData, PowerConsumerComponent, PowerGeneratorComponent and probably a lot more. This would also reduce the game's memory usage.

Data access

Other optimizations are a bit more difficult. These would be the data access optimizations. These optimizations reduce the number of indirections necessary to get to the data an entity actually cares about. It is quite easy to add an additional array that stores the network ID for each inserter so the network ID doesn't have to be fetched from EntityData with a random access memory request. But doing so means duplicating information in multiple places. Updating this kind of information would require updating it in multiple places. It can quite quickly result in very complic