devtrackers.gg
They have a really clever solve for the issue of moving things on belts; as I understand it, they group everything on each section of belt with no splits or merges, keeping track of what is at each end. This means to move the entire belt they only have to take stuff off and put anything on each end, rather than update every item on the belt. Super cool!
Exactly, so belt update is basically O(1) regardless the length of the section. And don't forget that belt logic is fully multithreaded.
It's interesting how commonly repeated there is a misconception about belt compression and UPS effects. People saw the problem of handling gap-closure and perceived that as scaling with the number of gaps, rather than also being O(1) for a given belt even with the complexity of handling item removal and insertion.
Were the gaps themselves ever a factor affecting performance (edit: as in O(N) for the number of gaps, not just the length of the belt) in one of the earlier optimization passes of belt simulation?
The belt gaps affect the memory footprint of the belt contnets definition, but they only affect the performance when the belt is being compressed, but still, it always affects the last gap only, which can be accessed by O(1) again.