Performance optimization - post your saves

[quyxkh]

Performace is amazing, relative to .15 anyway. Im sure there is still a lot more i can do to squeeze out some more UPS, but its great when you guys do it for me

heres my save for your consideration. I dont know how to use less insterters to achieve the same throughput. im considering circuit controlled inserters out of smelters on a timer, so they can always move 12 items per swing, instead of 1-2, but i dont know if that would be better or worse overall. having some option for inserters to only activate if they can move the full 12 at a time would be great!

Or change nothing. or change everything. imo the game has only gotten better with every decision made so far!

*edit, if smelters could make 12 items at a time, that cost 12x the mats, and take 12x longer... that would be nice ))

Testing says by far the best when you're going for raw UPS is direct miner⇒smelter insertion with clocked smelter-unload inserters, have an `=1 ⇒ output 1` decider on the clock so the inserters only see the one pulse per cycle, DaveMcW found that matters too,for about a 10% boost (edit: over the rather dramatic boost you get from clocking them in the first place) in plates-per-cpu-ms. With late-late-game productivity bonuses the outposts will last a good long time, so the shifting needed to mine what was under the smelters before won't be much trouble.

[RainbowAndy]

Damn. Obvious now you've mentioned it, I just loved the wave defence side of the game.

Thanks heaps

[grokzen]

Rseding91: Interested in my old 0.15.x vanilla (works in 0.16.x also) 10k SPM giga base save? I am kinda done with that save so i have no use for it.

Not sure what you can use it for more then to test a real world giga base in development perhaps? It runs about 18-22 UPS on my system in 0.16.x and way lower in 0.15.x

[Rseding91]

Rseding91: Interested in my old 0.15.x vanilla (works in 0.16.x also) 10k SPM giga base save? I am kinda done with that save so i have no use for it.

Not sure what you can use it for more then to test a real world giga base in development perhaps? It runs about 18-22 UPS on my system in 0.16.x and way lower in 0.15.x

I can look at it but chances are it's nothing new and just "a lot of everything"

[grokzen]

Rseding91: I posted it to you in priv msg

[Aeternus]

I did notice a significant and persistent performance drop when I scheduled a large portion of my factory to be deconstructed (an old research production facility that I wanted to redesign). I have 2500 construction bots that can reach there but the order was far in excess of what those bots could handle. Eventually when the bots cleared the deconstruction performance returned to normal.
It looked like the game is continously trying to loop through the items-to-be-deconstructed, trying -and failing- to find a bot for each new item and then skipping and going for the next one. Might it help to issue that code a small 5 second stand-down code if no bots are found within the zone before trying more items?

On the plus side, the game, while running noticably slower, keeps a very responsive gui. You may move at half the speed but there's no stuttering. That is impressive, that kind of throttling when the game's chewing on more then it can stomache is something I've not seen in many games.

I can post a save it it's helpful (unmodded game started in 0.16.something, tweaked railworld settings).

[Rakshasa]

I did notice a significant and persistent performance drop when I scheduled a large portion of my factory to be deconstructed (an old research production facility that I wanted to redesign). I have 2500 construction bots that can reach there but the order was far in excess of what those bots could handle. Eventually when the bots cleared the deconstruction performance returned to normal.
It looked like the game is continously trying to loop through the items-to-be-deconstructed, trying -and failing- to find a bot for each new item and then skipping and going for the next one. Might it help to issue that code a small 5 second stand-down code if no bots are found within the zone before trying more items?

Having 5 second delays and such are not really very good solutions.

Instead you create per-network buckets for items awaiting idle construction bots, and wait for a trigger when a bot becomes available.

[ETM654]

The game runs pretty good on my potato, lags a bit with all my factories but that's to be expected the Major lag hit is when I zoom out or i'm by a group of trees.
last time I checked with the f5 (or 6 idk) key I got about 23fps as an average thats fine though, it goes down to 3 fps around trees. I think its mostly because of my graphics card not liking transparency.
I save a few fps by having clouds and smoke off and having the light resolution low.

[Burning_Chair]

Here's a save of a belt based factory that can do 600 science pack per minute. 32 belts of iron ore, 5,6GW reactor, other things. Just what happens if you play 100+ hours mainly using belts. On that playthrough i wanted to get a feel on the belts vs bots thing but i didn't get to build the bot based segment - the game could no longer run at 60 UPS. Admittedly my Core 2 Quad is slow by today's standards but from optimization point of view it just means that it's easier to reach the limits. So i decided to do some profiling of my own. Out of 17-18ms of game update 10-11ms were taken by entity update. So i decided to remove entities type by type and see which ones are the most expensive. I was surprised to find out that 8-9ms of game update we taken by inserters (almost 12500 of them), and after removing them of the remaining 7,5ms of game update half was taken by pipes, storage tanks, pumps - fluid handling in general.

Before anything was removed:

Without inserters:

Without fluids also:

Next i thought it would be interesting to test a few scenarios in which inserters might consume the most performance. I created a new game (save also attached) and using cheats simply built almost 14k of inserters and some other things for convenience. The results were:
-if the inserters are built next to nothing they consume noticeable chunk of time
-if there are empty chests or belts on their input - consumption goes down by a factor of almost 10
-if the chests aren't empty - consumption goes back up.

A couple of footnotes:
-On the main save if you remove all the enemy force, of the remaining 58k active entities 33k are fish.
-If you run something like this

Code: Select all

/c  local surface=game.player.surface  for key, entity in pairs(surface.find_entities_filtered({force="neutral"})) do  if string.find(entity.name, "tree") then   entity.destroy()  end end

the RAM consumption goes through the roof. Apparently depends on the number of entities destroyed.

[Jap2.0]

Are you sure performance rose from the lack of inserters and not the fact that your factory probably came to a standstill?

[Burning_Chair]

Are you sure performance rose from the lack of inserters and not the fact that your factory probably came to a standstill?

That's why the second save and some experiments with only inserters, chests and belts.

[Jap2.0]

Are you sure performance rose from the lack of inserters and not the fact that your factory probably came to a standstill?

That's why the second save and some experiments with only inserters, chests and belts.

...
...
It's almost like if you build almost an entire save of inserters, inserters will take a large portion of your processing time.
Remarkable!

[Burning_Chair]

Are you sure performance rose from the lack of inserters and not the fact that your factory probably came to a standstill?

That's why the second save and some experiments with only inserters, chests and belts.

...
...
It's almost like if you build almost an entire save of inserters, inserters will take a large portion of your processing time.
Remarkable!

I understand you thinking on both points. I should have given a more thorough answer.
Yes it occurred to me that it could have been assembly machines and furnaces that are not being fed anymore is what causing a big difference. I checked that by first removing them. Out of 17-18ms game update that saved only 3ms. What's left of the difference can be observed in the second save.
Yes, if there are only inserters it's completely logical that they take most of the time. What's important is how much time. If there are items to move (chests with stuff) or just ground on the input, the amount of time 14k of inserters take to update is pretty much the same as the difference i get after removing them in the main save.

[Jap2.0]

Are you sure performance rose from the lack of inserters and not the fact that your factory probably came to a standstill?

That's why the second save and some experiments with only inserters, chests and belts.

...
...
It's almost like if you build almost an entire save of inserters, inserters will take a large portion of your processing time.
Remarkable!

I understand your thinking on both points. I should have given a more thorough answer.
Yes it occurred to me that it could have been assembly machines and furnaces that are not being fed anymore is what causing a big difference. I checked that by first removing them. Out of 17-18ms game update that saved only 3ms. What's left of the difference can be observed in the second save.
Yes, if there are only inserters it's completely logical that they take most of the time. What's important is how much time. If there are items to move (chests with stuff) or just ground on the input, the amount of time 14k of inserters take to update is pretty much the same as the difference i get after removing them in the main save.

Ah, okay, thanks for clarifying.

[posila]

Inserters picking from/to ground are updated every tick as opposed to inserters that are transferring between two entities and can sleep on those entities.

[mrvn]

Inserters picking from/to ground are updated every tick as opposed to inserters that are transferring between two entities and can sleep on those entities.

So when using multiple inserters to transfere items from A to B one should always put a belt or chest at the exchange points.

[Oktokolo]

So when using multiple inserters to transfere items from A to B one should always put a belt or chest at the exchange points.

Also inserters generally are faster if they have to open a box first before picking or putting an item.

[peet1993]

Hi,

AntiElitz played a Sub Event and people tried to deconstruct the starter base a bit too fast, so 5000 bots where doing that at once and the Construction manager got up to 13ms update time (more than the actual base needed to run).
Here is a save when that happened: https://www.dropbox.com/s/ynfo3yylifwd9 ... r.zip?dl=0
I think it could have to do with the many deconstruction orders, especially all the items on belts and maybe the heavy bot charging. Just a wild guess. Maybe you can achieve something with it!

[fochristo]

Just a question : after all the belts optimisations, is it always better for cpu optimisation to use underground belts instead on lines of belts ?

[Trebor]

Ver 16.32. I've a question about the idle power usage of inserters. Almost everything in the attached save is turned off and I noticed the inserter power usage runs through a cycle of heavy/light every few seconds. I thought the idle usage would be steady.


EDIT: Ok maybe it's just me not paying attention. Last night it looked like it was cycling, after uploading I started it up and usage was steady. Then I remembered I had turned off radars in the power usage window (filter settings didn't get saved). After turning off radars the inserter bars looked like they were cycling. Turns out it's actually the miners cycling but the inserter power bar changes size because it's displayed relative to the miners.