The logistic network knows which chests have space for a given item type VS. have empty slots so it can skip virtually all of those checks and go right to a chest that it knows has room. So, at most it does: final chest slot count number of checks when it goes and inserts the item(s).apriori wrote:Ok, now I see... I'm not enough experienced factorio modder yet, but have a couple ideas about how to solve this issue - I should check it out. Is there a way to override standard inventory check method?
Look, if I have 1.5M plates in 10 warehouses of 1.5k slots each OR in 300 shests of 50 slots each - isn't it the same for game performance? In both cases 15k slots will be checked by inventory logic. Or I shouldn't have such stocks?
It's enough to optimize my storage facility, thank you, Rseding91. As I undersrtood, it means, that I shouldn't put items into warehouses (any of them) using inserters - only with robots and only into yellow (storage) warehouses. Of course if I want to place a lot of them without causing UPS decrease. Correct?Rseding91 wrote: The logistic network knows which chests have space for a given item type VS. have empty slots so it can skip virtually all of those checks and go right to a chest that it knows has room. So, at most it does: final chest slot count number of checks when it goes and inserts the item(s).
Sorry for the necro bump though I don't think that matters in this forum. However, from your description, the way inserters work seems rather naiive and not a very efficient/performant way for inserters to work, and particularly causes problems with mods like this. If you've already change this since then, that's fine, ignore this.Rseding91 wrote:I don't consider this a bug as the mechanics are all working exactly as expected. You've simply cranked the numbers far beyond what they where intended to be which is (as you're seeing) hurting performance.
A more technical description of what's causing it to run slow: Every time an inserter looks to insert something into the large inventory it gets the item and it asks the inventory if it can insert any of it. The inventory logic iterates over each available inventory slot it has and checks if it's blank or the count is < the stack size of the item in the slot.
For an inventory with 1800 slots that means it has to do that check somewhere between 1 and 1800 times for each "can insert" check run against it. As the inventory gets fuller the stacks at the front start to return false for that check and so the number of checks per item inserted goes up.
There might be some potential for optimization here but the use case is so small that it's probably not worth the time to look into this. What you could do instead is have the assembling machines export into active provider chests which the robots will then move off into the next available logistic storage chest and then request those items in the final destination. The robots will auto-find a valid chest for items and auto-find valid chests with items for picking up. You can expand that far more without hurting performance since each inventory is smaller and doesn't have a constant stream of items being put into and out of it.
The cost of maintaining such a dictionary and indexing into it to find information is almost the same as simply iterating the inventory contents. In fact probably more because you have to maintain essentially the same data structure that the inventory has but the possible index size is *much* larger - all item types in the game (hundreds) for an inventory that's of size 50~ would be an incredible waste of memory.clusterfack wrote:Sorry for the necro bump though I don't think that matters in this forum. However, from your description, the way inserters work seems rather naiive and not a very efficient/performant way for inserters to work, and particularly causes problems with mods like this. If you've already change this since then, that's fine, ignore this.
If not, allow me to propose to you how I would optimize them were I given your code, and a bit of free memory.
First, track the first empty slot of the chest on the chest entity.
Second, track the less than max size stacks within the chest using a dictionary that holds the types of all entities within the chest that have at least one entry that is less than max stack size. The dictionary points to a list containing all the slots that these <max stacks are holding.
If you want it to always insert in 'the first slot that can accept an entry', you make sure that when you add a value to the <max size stack list, it gets sorted into the correct position. Then you can compare entries of the list versus the tracking value of the first empty slot of the chest.
Or to be slightly faster, and use less memory you could have it insert using 'fill <max stacks first, then insert into first empty slot', which would require no sorting of the list whatsoever, and help keep the memory cost of the dictionary/lists much lower (on an aggregate scale) as well.
