TL;DRA discussion on UPS on Reddit suggested that inserters -> chests are a performance bottleneck in Megabases.
ichaleynbin wrote:The only thing I'd mention is that if you're working on that scale, one of the bigger UPS penalties isn't inserters, so much as inserting into chests, because each chest insertion has to iterate all of the currently present stacks. If your chests are doing anything, then they're hurting your UPS.
What ?Consider the problem where a chest has iron ore stacks of [10, 0, 0, 50, 0...]. (10 iron ore in the first stack, two empty stacks, 50 ore in the 4th stack, and the rest of the chest as empty]. It seems like the game currently walks all of the "stacks" every insertion.
As a suggestion, maybe the game should only recalculate chest-stacks under two conditions: when a "non-common" item is inserted into the chest (ie: copper plates are inserted into a chest normally filled with iron ore), or when the player opens a chest. In all other cases, it seems like two counts: "Common Item Inserted" and "Common Item Removed" are the only values needed to keep track of. This would reduce the number of "internal chest organization" calls and potentially optimize the game for Megabases a bit better.
For example: a chest with iron ore stacks of [10, 0, 0, 50, 0, ...] has 16 iron ore removed from it, then 100 iron ore added to it. This should result in an internal stack of [50, 50, 0, 44, 0, ...] afterwards. The other ordering (100 ore added then 16 removed) would be equivalent to 84 items added (resulting in an internal configuration of [50, 34, 0, 50]).
If behavior needs to be 100% kept with previous versions, you can potentially recalculate stacks whenever a "new" item gets inserted into the chest. For example, if 16 iron ore is removed, then 100 iron ore is added, but a copper-plate was added "somewhere in between", you'd either have [50, 1-copper, 50, 44] or [50, 50, 1-copper, 44], depending on the ordering. I'd expect that this difference wouldn't affect most people's bases (most "mixed chests" are either logistic chests or are interfaced with filter-inserters). So this edge case can arguably remain ill-defined for performance reasons. Otherwise, you can simply recalculate stacks whenever item insertions change, since I expect this case to be relatively rare (aside from logistic requester chests).
Why ?At least one megabase player has started to avoid chests, due to perceived UPS problems. Further testing is probably necessary, but I feel like the devs of this wonderful game should be aware of the issue. It seems like an easy fix (although I know that in reality, nothing is ever easy in programming). Well, easy compared to belt-optimizations anyway. But I feel like letting yall know about it might be useful.
In short: I have a performance suggestion that might be relatively easy to accomplish. Thanks for hearing me out!