Dual inserter mechanic

[WeirdConstructor]

Otherwise I am thinking that an easy fix to the the core problem could be a "single item type" checkbox that could be applied to chests. When the flag is checked, only one kind of item is allowed and then the chest no longer needs to check every slot... just the total quantity. UPS problem... gone.

If you can single-handedly reduce the cost of chest insertions to O(1) i'm sure the devs would be very interested. Alas i doubt it's quite as simple as you think. But that's a discussion best left for other threads.

The thing is mostly, that a O(n) operation is not necessarily expensive. It is usually O(c * n), where c is a constant. If c is very low, the operation can be comparably cheap to an O(log n) or O(c_2 * 1) operation, where c_2 is high. If c_2 * 1000 = c, then a O(c * n) is less expensive for any n < 1000. The O notation is only about wort case. Only judging an algorithm by that does not suffice to estimate real world costs of an operation.

I believe that the inserter add/remove can be optimized for very large chests in some mega bases. For example, you could store a pointer to the first free slot in the chest. So an add operation become O(1). But it means you have to update that pointer each time an add or remove is done. That adds overhead. Not only do two operations have to take care of the pointer, which adds maintenance overhead to the code and which can add a source of bugs. But you suddenly have to solve the problem of finding "the next free slot" after an add/remove operation. For remove it's pretty easy. But for add you have to iterate to the next free slot, which is O(n) too (worst case obviously). And there you have O(n) again, just that the c got more expensive (memory overhead of pointer and maintenance overhead of more complicate code). And we did not even talk about reserved slots yet. And next we talk about branch prediction of modern CPUs, which can make code with lots of "if" statements much slower than some simple "for" loops over a linear array in memory.