PoolTrim

PoolTrim

look at me in chinese

PoolTrim trims excess reserved space in conveyor paths and building data when loading files, reducing the memory footprint of large archives. You can also turn on ColdGeometry to losslessly compress the coordinates and orientation of the conveyor belt to further save memory. This option is off by default.

900w sugar archive actual measurement

Archive size is 46.68 GB and contains 266 built planets. The following table compares the performance of the same archive under different optimization conditions. The memory is uniformly used in decimal GB:

| Metrics | PoolTrim not enabled | Enabled (capacity trimming only) | ColdGeometry enabled |

|---|---:|---:|---:|

| Reading time (archive import) | 233.54 seconds | 167.42 seconds | 226.88 seconds |

| The process commits memory after reading the file | 131.04 GB | 78.41 GB | 67.67 GB |

| Conveyor path array capacity | 66.21 GB | 20.72 GB | — |

| Entity and adjoint array capacity | 18.66 GB | 15.90 GB | — |

| Route point utilization rate | 31.3% | 100% | — |

Capacity clipping reclaims approximately 45.49 GB for the conveyor path and approximately 2.76 GB for the entity and companion arrays, for a total reduction in array capacity of approximately 48.25 GB. With ColdGeometry enabled, the cold path geometry data is compressed from approximately 19.56 GB to 8.78 GB, saving another approximately 10.78 GB. Compared with capacity trimming alone, the process commit memory is reduced by approximately 10.74 GB, and file reading takes approximately 59.45 seconds longer.

Configuration items

After starting the game for the first time, the configuration file BepInEx\config\fyyy.dsp.pooltrim.cfg will be generated. You need to restart the game after modifying the configuration. Capacity clipping is always enabled.

• ⚠️ RISK: ColdGeometry (Default: false / off by default, in [Performance])
• Effect: When reading a complete file, the point coordinates and orientation of the conveyor belt are losslessly compressed. When the data is needed for display, construction or editing, restore it by the path. Cargo occupancy, route connections and transportation logic still use the original data.
• Cost: Save running memory, but load files slower. Decompression is also required when visiting a planet for the first time and when saving. Paths that have been restored, edited, or created remain uncompressed until the archive is reloaded, so the memory savings may gradually decrease.
• To take effect: Change the configuration value to true and restart the game.

Optimization principle

Conveyor path: actual length vs. reserved capacity

The game will merge a continuous conveyor belt into a path (CargoPath), and divide points along the path to record the location of the goods. Each point occupies one entry in each of the three arrays, totaling 29 bytes:

| Array | Content | Occupied by each point |

|---|---|---:|

| buffer | cargo occupancy status | 1 byte |

| pointPos | Point coordinates (Vector3) | 12 bytes |

| pointRot | Point orientation (Quaternion) | 16 bytes |

The actual length is the number of points in use by the path, and the capacity is the number of slots in the array that have been allocated.

• When paving tape to extend the path, the game will expand the array capacity.
• After the path is removed and cut off, the path becomes shorter, and the existing array will still retain its original capacity; when the old path object is reused, its reserved space will also be used.
• When saving, the game only writes the data within the actual length, and also writes the capacity value into the archive.
• When loading files, the game first allocates three arrays according to the capacity in the archive, and then fills in the actual data.

After many renovations in an old factory, the array may be much larger than actual needs. The total path capacity of this 9 million sugar archive is about 2.283 billion points, but only 714 million points are actually used, and the remaining …