PoolTrim

PoolTrim

中文看我

PoolTrim 在讀檔時裁剪傳送帶路徑和建築數據中多餘的預留空間，減少大型存檔的內存佔用。還可以開啓 ColdGeometry，無損壓縮傳送帶的座標和朝向，進一步節省內存。此選項默認關閉。

900w糖存檔實測

存檔大小 46.68 GB，包含 266 個已建廠星球。下表對比同一存檔在不同優化條件下的表現，內存統一使用十進制 GB：

| 指標 | 未啓用 PoolTrim | 啓用（僅容量裁剪） | 啓用 ColdGeometry |

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

| 讀檔時間（存檔導入） | 233.54 秒 | 167.42 秒 | 226.88 秒 |

| 讀檔後進程提交內存 | 131.04 GB | 78.41 GB | 67.67 GB |

| 傳送帶路徑數組容量 | 66.21 GB | 20.72 GB | — |

| 實體及伴隨數組容量 | 18.66 GB | 15.90 GB | — |

| 路徑點位利用率 | 31.3% | 100% | — |

容量裁剪爲傳送帶路徑回收約 45.49 GB，爲實體及伴隨數組回收約 2.76 GB，合計減少約 48.25 GB 數組容量。啓用 ColdGeometry 後，冷存的路徑幾何數據從約 19.56 GB 壓縮到 8.78 GB，再節省約 10.78 GB。相比僅容量裁剪，進程提交內存減少約 10.74 GB，讀檔多花約 59.45 秒。

配置項

首次啓動遊戲後，會生成配置文件 BepInEx\config\fyyy.dsp.pooltrim.cfg。修改配置後需重啓遊戲。容量裁剪始終啓用。

• ⚠️ RISK： ColdGeometry (Default: false / 默認關閉，位於 [Performance])
• 效果: 完整讀檔時，無損壓縮傳送帶的點位座標與朝向。顯示、建造或編輯需要這些數據時，再按路徑還原。貨物佔位、路徑連接和運輸邏輯仍使用原版數據。
• 代價: 節省運行內存，但讀檔更慢。首次到訪星球和保存時也需要解壓。已還原、編輯或新建的路徑會保持未壓縮狀態，直到重新讀檔，因此節省的內存可能逐漸減少。
• 生效: 將配置值改爲 true 並重啓遊戲。

優化原理

傳送帶路徑：實際長度與預留容量

遊戲會把連續的一段傳送帶合併成一條路徑（CargoPath），沿路徑劃分點位來記錄貨物的位置。每個點位在三份數組中各佔一項，合計 29 字節：

| 數組 | 內容 | 每個點位佔用 |

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

| buffer | 貨物佔位狀態 | 1 字節 |

| pointPos | 點位座標（Vector3） | 12 字節 |

| pointRot | 點位朝向（Quaternion） | 16 字節 |

實際長度是路徑正在使用的點位數，容量是數組已經分配的槽位數。

• 鋪帶延長路徑時，遊戲會擴大數組容量。
• 拆帶、切斷路徑後，路徑變短，已有數組仍會保留原來的容量；複用舊路徑對象時，也會沿用其預留空間。
• 保存時，遊戲只寫入實際長度內的數據，同時把容量數值寫進存檔。
• 讀檔時，遊戲先按存檔中的容量分配三份數組，再填入實際數據。

老工廠經過多次改造後，數組可能遠大於實際需要。這個 900w 糖存檔的路徑總容量約 22.83 億點，實際只用了 7.14 億點，其餘約 15.69 億點都佔着數組空間。

PoolTrim 在 CargoPath.Import 完成後，調用遊戲自己的 SetCapacity(max(1, 實際長度))，把三份數組一起縮到實際使用範圍。遊戲將有效數據複製到較小的數組，舊數組隨後由垃圾回收器回收。空路徑至少保留一個槽位，讓原版擴容邏輯能繼續工作。

實體及伴隨數組：按同一編號一起縮容

每座建築都有一個實體編號。建築本身的數據，以及它的動畫、狀態標記、連接關係等，分別存放在多份數組中，使用同一編號索引。例如，編號爲 1000 的建築，會使用實體、動畫和狀態標記數組的第 1000 項。

這組數據包括實體、動畫、狀態標記、連接數組，以及互斥鎖引用、需求引用和回收編號數組，合計每個容量槽位 384 字節。

PoolTrim 保留整段已用編號範圍，一起裁剪這些數組末尾的空閒空間。拆除建築後留在中間的空位，仍由原有回收列表管理；現有編號、連接數據和回收順序保持原樣。

裁剪時會按已用編號範圍額外預留 12.5% 的空間，至少保留 1024 個空槽。只有能回收原容量的 12.5% 或更多時，才複製整組數組。這個存檔有 172 個工廠滿足條件，共回收約 718.30 萬個實體槽位。

ColdGeometry: 壓縮傳送帶點位數據

完整讀檔時，PoolTrim 對 pointPos 和 pointRot 中 float 的原始位模式做整數差分和字節分組，再用 Windows 自帶的 XPRESS_HUFF 無損壓縮。壓縮結果是保存在內存中的字節數組，與對應路徑關聯。兩份壓縮結果都準備好後，才釋放原來的幾何數組。整個過程不量化座標，也不重新採樣，負零和 NaN 的位模式同樣逐位保留。如果小路徑節省的空間還不夠抵消額外對象的開銷，就保留原數組。

運輸使用的 buffer、貨物編號和連接不變。顯示、建造、拆分或合併需要幾何數據時，PoolTrim 先完整還原座標與朝向，再交給遊戲使用。普通運輸不會觸發還原，離開星球也不會再次壓縮。只要路徑還在使用，正常垃圾回收就不會丟棄它的壓縮數據；路徑釋放後，這些數據纔可以一併回收。

保存時，PoolTrim 只臨時解壓正在寫出的座標或朝向，按原版格式寫入路徑數據，不把內存壓縮格式寫進存檔。它不增加外部數據文件，正常保存後可以移除插件再讀檔。

README

PoolTrim reduces memory use in large saves by trimming unused capacity in belt paths and building data during loading. You can also enable ColdGeometry to save more memory by losslessly compressing belt positions and rotations. This option is off by default.

9M white-science save results

The save file is 46.68 GB and contains 266 planets with factories. The table compares the same save with different optimization settings. All memory values use decimal GB.

| Metric | Without PoolTrim | Capacity trimming only | With ColdGeometry |

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

| Load time (save import) | 233.54 s | 167.42 s | 226.88 s |

| Post-load process commit | 131.04 GB | 78.41 GB | 67.67 GB |

| Belt-path array capacity | 66.21 GB | 20.72 GB | — |

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

| Path-point utilization | 31.3% | 100% | — |

Capacity trimming reclaims about 45.49 GB from belt paths and 2.76 GB from entity and companion arrays, for a total of about 48.25 GB in array capacity. With ColdGeometry, the geometry stored in compressed form shrinks from about 19.56 to 8.78 GB, saving another 10.78 GB. Compared with trimming alone, process commit drops by about 10.74 GB, while loading takes about 59.45 s longer.

Configuration

Run the game once to generate BepInEx\config\fyyy.dsp.pooltrim.cfg. Restart the game after changing it. Capacity trimming is always enabled.

• ⚠️ RISK: ColdGeometry (Default: false, section [Performance])
• Effect: Losslessly compresses belt positions and rotations when loading a full save. Paths are restored as nee