I finished the item stack optimisations mentioned in FFF-198, and was able to do some performance tests. First I tested how many stacks on a big map actually need to use an externally allocated object (Item), and how many of them are plain. On the huge map I tested, it turned out that only 36K out of 1M stacks need the Item object. These were mainly science packs, as they need it for the progress of how used-up they are (and now when I think about it, it could also be omitted by only using the objects for science packs that are partially used up already). Overall factory performance was increased approximately 2% by this. It is nothing huge, but every bit matters.
One of the programmer that has read access to the code (Zulan), came up with a pull request that improves performance in Factorio by prefetching memory in the update loops ahead.
The problem when normally updating objects is, that CPU asks for memory representing the object. The memory is slow, at least compared to the CPU cache or the CPU speed. The memory transfer speed itself is not that slow, but the waiting (latency) time between ordering and receiving it is. This means, that what very often happens is, that CPU orders data of next entity from the memory, then it waits for quite a long time to get it, and then it does its logic. The memory prefetching partially solves it by doing this:
As flexible and powerful as it is, we have always felt there was one key missing to the puzzle. The main issue is that requester chests cannot provide their items to any other member of the logistics system. Trying to workaround this by putting an inserter to a passive provider, just leads to the robots moving the items in a loop. This is also a nuisance trying to supply construction robots with materials, as they can only collect them from storage or provider chests, and they are only typically located in the main base areas.
It is easy to design a system to resupply far out areas using trains to directly put items in provider chests, but if they are in the same logistic network we encounter the same loop as before. We were also concerned of people segregating their logistic networks for more control, it seems to us it was a workaround to a problem we should fix. The solution is the buffer chest, which functions as both a requester and passive provider chest.
You can see the buffer can act as an 'in-between' for storage/provider chests and the requesters. This leads to a solution of the main annoyances we identified.
Typically when you set up all the provider chests, they are spread out across your whole factory. When you return to base for a resupply, you end up waiting for a long time while the bots travel from all over the factory with items. By using a buffer chest, you can setup a dedicated 'supply area', where the buffer chest will already contain all the typical items, and the bots can quickly top-up your inventory.
Another problem is when you have a large perimeter defence, and you want it to be maintained by the construction robots. When the main base is so far away, it can take a long time for robots to arrive with repair packs, so the biters might be able to break through. Using the buffer chest, it will be easy to setup nearby supplies to quickly repair the walls when needed.
Last, but not least use-case is when you want to dedicate part of your storage for specific things. The reason can be either just OCD, or the fact, that you can make sure that too much coal for example won't make it impossible to store enough of iron ore in your storage system.
As always, leave us any feedback or comments on our forum
