Factorio Forums

I was running some tests to see how UPS were affected by belts/chest/inventory size etc.

However, when I tested linked chests, they seem to take longer to process (higher ms cost and lower ups) when you have more of them linked, but disproportionately so.
In this setup, I have 180K linked chests (all linked to the same inventory) and 100 inserters. The Update time is 45 ms. The problem occurs only with the linked-container prototype, and only when the chests share an ID. Extra details provided below:

In editor I tested a lot of setups. To summarize:

72K inserters, 36K assemblers and belts. Update 9.8 = ms.

72K inserters, 72K 1-slot chests and 36K assemblers. Update = 10 ms.

72K inserters, 72K 1-slot linked chests (fixed slot amount, not increasing with each linked chest. Modified the inventory size of the vanilla linked-chest prototype) and 36K assemblers. Update = 240 ms, but some spikes creep to 480 ms.

72K inserters, 36 1-slot chests (super wide chests using MergeChests mod) and 36K assemblers. Update = 11 ms.

At first I thought - clearly more entities will cost more UPS, so linked-chest isn't the problem. However, using 1-slot chests (simple containers) uses the same amount of entities and works as well as belts.
Then I thought - perhaps many inserters interacting with the exact same inventory are causing the problem (doing something like reserving items (Rseding91 confirmed inserters don't reserve items, thanks!)). However, using the WideChests mod, I don't notice UPS problems when upwards of 2K inserters are interacting with the same inventory (Update is just 1 ms higher than individual chests).

I managed to boil down the problem to a simple setup that presents the performance problems without any mods - save attached as "LinkedChestScaling".

I can reproduce the issue in new saves. But as an extra bit of information - I can create a new world and build the setup until each update takes ~15 ms in my machine. But then when I save and reload the same save, now each update takes ~48 ms as depicted in the screenshot (!). It happens with or without Space Age enabled.
Also, the issue only happens if the linked chests are all linked to the same inventory. If 179.9K chests have a linkID=2 and only 100 linked chests (the ones interacting with the inserters) have linkID=1, the performance cost doesn't happen.


I'm making a bug report because when communicating with other people in Discord, we all thought the behavior seemed weird - we didn't expected linked-container "networks" to have a higher UPS cost when more containers were added, we only expected them to be pricier when the inventory had more slots or when more inserters interacted with it.

Thanks for your time

Thanks for the report however this is all to be expected. Every time the inventory changes the change notification has to be forwarded to every linked chest using that inventory. So naturally, more linked chests using the same inventory will mean more chests to forward notifications to as they happen.

The events have to be sent to the chests so they can wake up inserters that may be sleeping in the chests. The linked logic has no way to know if a given linked chest has sleeping inserters until it has already forwarded the change notification to it - at which point the performance cost has been paid.

Thanks for the swift response!

As an added question - Are these forwards tick instantaneous ?- as in, there is no delay like in circuit networks.

Also, the behavior where the setup takes 15 ms upon creation but 45 ms upon load is expected?

Yes they are instant and happen instantly as the item has been added or removed.

As for the reload having worse performance, I’d have to profile it to see, but I suspect it’s cache access order and it getting scrambled when saving and loading. I won’t be able to profile it until tomorrow but if I find anything interesting I’ll report back.

Thanks!!

I profiled the save file and found some areas to improve for the next release.

Thanks for all your work

Rseding91 wrote: Thu May 15, 2025 6:31 pm I profiled the save file and found some areas to improve for the next release.

I might be missing something here but just wanted to report that I tested the same setup in 2.0.50 (180K linked chests all linked to the same inventory and 100 inserters). I think now not only the save-scrambled Update=45 ms was fixed, but the performance improved from Update=15 ms to Update=0.2 ms (!!!)
Absolutely amazing work!

Also it might be useful to report that proxy containers did not enjoy the same performance uplift.