I'm building a megafactory to use as a sandbox, and it has a massive ore storage facility. At present, the ore storage facility is several lines of alternating steel chests and stack inserters. Belts feed the ore to be stored into the setup and the ore is then carried down the line by the sequence of inserters. At the other end, it is put onto another train and taken to the smelters. I've attached a screenshot. The setup as-is has 174k stack inserters and I am still expanding it to hold more resources.

I think that it is this massive array of stack inserters that is slowing my game down; pressing F5 and looking at the gobbledegook there tells me that my entity update is very resource intensive. I am wondering if switching to a logistic bot based resource dump would be a stronger idea. Can someone familiar with the various optimisations provide me with advice on whether switching to bots would be worth it please?

Great idea, and normally that's how I'd be doing it. But I want to avoid having to build over resource patches, so I need to mine areas out and store the resources. Plus, I want my production spikes to potentially be quite long.

But i found it easier to just plan around the ore-patches and use them in priority.
I think most of the the time there is enough to be done to have the needed patches to get empty....

On secund thought, the farter out the patches the richer they are, so why waste time for the small patches and built the infrastructure twice then ?
-> just overbuild and take the next richer patch (which you eventually need anyway)

-----------
as for bots (i avoid using them, because i feel they take out much of a chunk of the game-principle)

you need less space because you can place chests denser.
You will need as much bots as you will need to fill the storage + the outgoing (don't forget the roboport for that much bots, and the needed energy)
i don't know of the impact on the performance

Much as I appreciate the gameplay advice, that is all stuff that I already know and it isn't related to the question I asked.

I don't mean to be rude but I am interested in the topic and I don't want the thread to be buried under off-topic replies. Please keep this as a thread on optimisation and PC performance. Anyone have any insight please?

Bots are much more ups friendly and your storage will be more compact wich is more UPS friendly in itself.
(Can you post the numbers you get? we can make a comparison then)
What is your megabase production goal?

When my base is at a stage to upgrade production, I usually start smelting/fabricating at mining sites, and store the intermediates. (Steel, iron plate, copper plate, green circuits)

Are materials constantly moving through the storage?
I'm guessing a bit but I think it should not consume that much of time.
Inserters will fall asleep when there is nothing to do so when receiving chests become full all the inserters should be sleeping and they won't consume update cycles until woken up.

Are materials constantly moving through the storage?
I'm guessing a bit but I think it should not consume that much of time.
Inserters will fall asleep when there is nothing to do so when receiving chests become full all the inserters should be sleeping and they won't consume update cycles until woken up.

The way I understand the OP is that he has a 'matrix' of chests with resources moving horizontally in the rows from source to sink. Or is delivered, possibly balanced in some way, to the left, and then moves through the inserters to the last non-full chest.

This would imply the problem is that whenever a single ore is taken out of storage, potentially the whole row needs to be activated, since it creates room in the last chest.

A non-bot solution could be to have a way to only activate the storage if the last chest is either low (to withdraw stored widgets) or too full (to store the surplus). E.g. create a 'current account' chest, with four stack inserters around it:
- Source delivers to this chest whenever there's material to be delivered
- Sink draws from the chest whenever there's demand
- Deposit moves from the chest to the storage ring when the balance is too high
- Withdraw moves from the storage ring to the chest when balance is too low

Since the storage ring is presumably 3xn tiles, you can add shortcircuits so it only activates the size of the storage ring needed.

Problem of course is this won't fit into a single row, so the system would be less space efficient and less easily suited to have a source train on the left and a sink train on the right.

Orzelek, the answer to your question is yes, materials are constantly moving through the storage. vanatteveldt has nailed the issue with his statement. I have separated the matrix up so that belts can load at three intermediate points in the storage, hence reducing the number of inserters that activate to move a handful of ore when a handful is extracted at the tail end by a factor of 4 as only a quarter of the inserters activate - this seems to help with power consumption so I am guessing it helps with CPU cycles as well. But it is still taxing the system by the seems of it.

Adding circuits to control it is likely to use more CPU than it saves I think...

I dunno how efficient bot storage would be. With a string of chests every inserter has 1 job. With a gigantic storage facility every bit of ore has to scan through storage until it can find an appropriate chest to use. If the facility doesn't have too much throughput it'll probably be okay, but if you're running all the resources through a massive storage buffer then there is a real potential for slowdown.

Consider breaking up the storage facility into smaller networks. I don't know enough about code internals to say if it will or won't help but maybe.

Ideally it's better to not run a massive storage facility at all. Stream resources through the factory, and build over ore patches if you have to. After you clear more land, use the power of blueprints to move the factory off the dirty land and on to the freshly cleaned land.

Orzelek, the answer to your question is yes, materials are constantly moving through the storage. vanatteveldt has nailed the issue with his statement. I have separated the matrix up so that belts can load at three intermediate points in the storage, hence reducing the number of inserters that activate to move a handful of ore when a handful is extracted at the tail end by a factor of 4 as only a quarter of the inserters activate - this seems to help with power consumption so I am guessing it helps with CPU cycles as well. But it is still taxing the system by the seems of it.

Adding circuits to control it is likely to use more CPU than it saves I think...

I guess the only way to know if bots are better is to try it!

I suggest a sytem in which you load from a belt into chest #1. The belt continues, e.g. with undergrounds. Chest #1 unloads on this belt, i.e. after the underground, AND into chest #2. Chest #2 loads into chest #3, etc. Chest #N unloads on the belt (which doesn't happen if the belt is full in the first place, and thus reduces UPS as soon as the storage is idle).

Since Chest #1 needs to connect to 3 inserters, this setup will only be compact if you put a piece of belt between chest #1 and chest #2. I would use this to unload from this belt (which is separated from the belt in the last paragraph) into 3 chests. You wanted a big storgage anyway!

I'm building a megafactory to use as a sandbox, and it has a massive ore storage facility. At present, the ore storage facility is several lines of alternating steel chests and stack inserters. Belts feed the ore to be stored into the setup and the ore is then carried down the line by the sequence of inserters. At the other end, it is put onto another train and taken to the smelters. I've attached a screenshot. The setup as-is has 174k stack inserters and I am still expanding it to hold more resources.

Why do you think that such massive storage is necessary? Undoubtedly the most UPS-friendly solution would be remove the whole thing. I have never found a situation in which 6 chests per wagon has been too small storage. It can store more than 7 trainloads stuff. And if you use maximum 12 chests per wagon for maximum speed of loading/unloading you can store 14 trainloads.

I think that it is this massive array of stack inserters that is slowing my game down; pressing F5 and looking at the gobbledegook there tells me that my entity update is very resource intensive. I am wondering if switching to a logistic bot based resource dump would be a stronger idea. Can someone familiar with the various optimisations provide me with advice on whether switching to bots would be worth it please?

I have no experience in this kind of massive storages, but as far as I know, bot logistics is generally clearly faster than belts and inserters. Bots are almost teleporting, they do not make any tests or run through animated working cycles. If you want to get as large storage as possible, it is probably better to change fully robotized logistics, even it may feel boring. It would also be more room effective and give possibility to sorting operations.

Stack inserters are fine, but here there are masses of parallel inventory interactions with ore passing through multiple chests; the more unfilled chests the greater number of interactions. You'll then hit the same problem when you try to empty them (at which point your base might be even more UPS sensitive).

Bots would probably help in that one regard, because each bot can transfer directly from provider chest to the "final" storage chest. But with a large number of storage inventories in the robot network, and with a large logistics area to cover, it'd probably still be very expensive on UPS. Whereas bots can be good at e.g. train unloading in a very localized area, this storage area is quite substantial, even if compressed by removing the inserters. I think there will be a lot of charging time and scanning for free roboports.

There are no two ways about it, this is a pathological scenario. Reducing work in progress and inventory interactions are the problems we're trying to solve in megabase design, just like in real world logistics. It's pretty much the thing we need our bases not to do.