[2.1.17] 192 Spoiled priority stack inserters drastically spike inserter performance cost
Posted: Tue Sep 01, 2026 6:22 pm
Hello!
We noticed that our megabase producing ~115K science packs of all kinds experiences serious UPS drops when Nauvis cargo landing pad is loading a train with agriculture science packs using 192 stack inserters with the Spoilage priority filter in either fresh first or spoiled first setting.
Depending on these 192 inserters using spoilage priority or not the entire megabase's inserter performance in entity time usage is either 7-8ms when these 192 inserters have the spoilage priority setting turned ON or 2-3ms when the spoilage priority is OFF.
This means that these 192 inserters using the spoilage filter cause more load on the save than the ~60K rest of the inserters in the save.
This behaviour might be intentional based on how sorting inventories work but the use-case of unloading the freshest packs to use in the labs seems intuitive and the performance impact not apparent to the average user.
It might only become a real issue when working with the ~60K slot inventory of the cargo landing pad and having to sort ~600K agriculture packs that are being kept in stock.
I have uploaded a save while which has the inserters with spoilage priority OFF here: https://drive.google.com/file/d/1Mqh_g9 ... drive_link
To reproduce the issue I left a ghost copy of the agriculture science pack unloading inserters including train track above the cargo landing pad on Nauvis with the spoilage priority set to Spoilage priority = Fresh first. Copy this over the [item=agricultural-science-pack][virtual-signal=signal-star]Load train station's unloading area overwriting the existing inserters and observe the UPS spike when a train is being unloaded at this station.
You can also undo the copy-paste of the inserters mid-unloading and notice the performance of inserters drop by about half.
I've attached 2 images as well showing the difference in entity time usage based on the setting of this single train unloading station's worth of 192 inserts with the ~2ms vs. ~8ms times visible.
We noticed that our megabase producing ~115K science packs of all kinds experiences serious UPS drops when Nauvis cargo landing pad is loading a train with agriculture science packs using 192 stack inserters with the Spoilage priority filter in either fresh first or spoiled first setting.
Depending on these 192 inserters using spoilage priority or not the entire megabase's inserter performance in entity time usage is either 7-8ms when these 192 inserters have the spoilage priority setting turned ON or 2-3ms when the spoilage priority is OFF.
This means that these 192 inserters using the spoilage filter cause more load on the save than the ~60K rest of the inserters in the save.
This behaviour might be intentional based on how sorting inventories work but the use-case of unloading the freshest packs to use in the labs seems intuitive and the performance impact not apparent to the average user.
It might only become a real issue when working with the ~60K slot inventory of the cargo landing pad and having to sort ~600K agriculture packs that are being kept in stock.
I have uploaded a save while which has the inserters with spoilage priority OFF here: https://drive.google.com/file/d/1Mqh_g9 ... drive_link
To reproduce the issue I left a ghost copy of the agriculture science pack unloading inserters including train track above the cargo landing pad on Nauvis with the spoilage priority set to Spoilage priority = Fresh first. Copy this over the [item=agricultural-science-pack][virtual-signal=signal-star]Load train station's unloading area overwriting the existing inserters and observe the UPS spike when a train is being unloaded at this station.
You can also undo the copy-paste of the inserters mid-unloading and notice the performance of inserters drop by about half.
I've attached 2 images as well showing the difference in entity time usage based on the setting of this single train unloading station's worth of 192 inserts with the ~2ms vs. ~8ms times visible.