Suggestions for speeding up factorio

[Cine]

TL;DR

Speed improvements

What ?

1. Have a flag on inserter to only start moving when have full stack to grab. Alternatively, when "override stack size" is set, use that as the exact amount to grab.
2. Have a flag on roboport(s) to only pickup once there is >= carrying capacity in the chest (robot should be dispatched to the chest, but not pick up the item until its carrying capacity is fully used). Alternatively, setting on the chest.

In both cases, it will prevent the wakeup lists for the derived entities from waking up. It also has the advantage of visually showing the amount of resources moved.

3. Increase minimum in-factory input and output buffer to that of 2x stack inserter capacity. Otherwise 1. wouldn't work.

4. Train destination algorithm needs to take into account the number of trains heading to station for stations with shared names.

IE, right now when a train leaves a station X, ALL waiting trains in the network that is destined for station X will converge on that free station. The end result is that you have alot of trains cycling around chasing that free station. If the station kept track of amount of incoming trains when calculating cost, then most of the time, only 1 train would attempt to go there.

5. Electricity is something everyone aims to be > 100%, so therefore the system should assume that is the normal case. If one assumes that, you can trade off accuracy for speed, there is no particular reason for that calculation to take >5% of the update cycle. Right now, the power use and power generation is calculation in each tick, however it would not alter the game much if it is was done once per second instead. e.g. in a tick, record the power use and power generation, and then for every second use the previous second % of power.

6. Roboports are either lacking an indicator when 'show-active-state' is on, or they are always processed.

7. Inserters that grab from the ground are always active, or 'show-active-state' indicator is broken.

8. Radars are always active, or 'show-active-state' indicator is broken for them.

9. Please hide zeros when showing 'show-active-entities-on-chunk-counts' and don't display in minimap.

10. Miners and factories are active in every tick, despite the fact that they don't interacts with the world until they need to output an item. I assume the reason is productivity during power shortages (or in worst case someone has mixed the animation with the update loop), but since our assumption is that power >100%, combined with 5. it should only need to wake up once a second (atleast for that reason).

11. Rework fluid dynamics, so it is sleepable. Right now, a nuclear powered bot-based factory will spend about ~30% of the update loop in active fluid elements alone.

12. Turn of render loop when factorio is minimized.

Why ?

So we can build giiiiiga factories.

[Rseding91]

Roboports, inserters, radars, and mining drills have logic to do each tick which is why they're active.

• Roboports consume power and when out of power disconnect from the logsitic network and will no longer dispatch robots.
• Inserters have no way to know if an item has been added to the world at the location they want to grab.
• Radars consume power and scan chunks around them + generate chunks in the distance as they scan.
• Mining drills can have fluid + consume power and apply mining progress each tick.

That's all working as intended.

Regarding #1 and #2: those checks already account for virtually all of the time spent in those areas. Once the check is done it's almost free to have the inserter or robot just do the work instead of saying "nah not yet" - it wouldn't gain anything and probably would slow the normal simulation down from all the extra checks.

In virtually all cases it's not acceptable to not be accurate when it comes to power consumption which is why things work on a per-tick basis. Also mods can adjust power in any entity at any tick which changes if it can work or not. Mods can also change the active state of almost any entity which changes if it will work that tick or not.

None of these things if they magically took zero CPU time would enable any significant improvement in game performance. You might get an additional 5-10% in the extreme scenarios but you're not going to be able to double your factory size. The slowest 4 parts of the game are still: biters, belts, robots, and inserters. Simply because of the numbers of them that exist at once on a given map.

Turning off rendering when the game is minimized sounds like a decent idea. I don't know why you'd leave the game in that state but it's a logical thing to do and I don't think there's anything limiting us from doing it.

[bobingabout]

Turning off rendering when the game is minimized sounds like a decent idea. I don't know why you'd leave the game in that state but it's a logical thing to do and I don't think there's anything limiting us from doing it.

You've just built a factory, that you assume is going to work, to fully automate the production of a heavy item (Maybe the rocket silo?) and are waiting for... it to happen. Tab out, check your emails, watch a youtube video.

I can agree that this is a good idea to do, in fact, by default I assume ALL games turn off their graphics calculations when minimised. (I can have several games running at once in some instances, my CPU can handle multiple simulations at once, my graphics card cannot, and it's a pain when one of them continues to drain the life out of my graphics card when minimised. Is there any wonder I consider my graphics card the biggest limiting factor of my computer's capabilities?)

[Cine]

Regarding #1 and #2: those checks already account for virtually all of the time spent in those areas. Once the check is done it's almost free to have the inserter or robot just do the work instead of saying "nah not yet" - it wouldn't gain anything and probably would slow the normal simulation down from all the extra checks.

The problem occurs when you are doing things "too fast". IE, you have a smelter that finishes an iron, that triggers the inserter, which inserts into a box, which triggers a robot to come pick up, robot comes, picks up 1 item, delivers item in requester, inserter there inserts 1 item that was lacking. Thats a smelter, a inserter, a chest, logistics network, robot, chest, inserter, factory, a total of 8 entities that needs to be activated in that chain for a single item. IE, for a full stack of 12, we need 96 wakeups.

If (1.) was in effect, then for a stack it would trigger smelter 12 times, inserter 12 times, chest 1 time, logistics 1 time, 3 robots, 3 deliveries to chest, 3 inserter checks, 1 factory insert, for a total of 36 wakeups, or 37.5% of the original.

If (2.) was in effect, but not (1.) it would trigger smelter 12 times, inserter 12 times, chest 12 times, logistics 12 times, 3 robots, 3 deliveries to chest, 3 inserter checks, 1 factory insert, for a total of 58 wakeups, or 60% of the original.

This doesn't even take into account that the logistics network and robot pathing is probably vastly more expensive than a simple inserter movement.

[Cine]

In virtually all cases it's not acceptable to not be accurate when it comes to power consumption which is why things work on a per-tick basis. Also mods can adjust power in any entity at any tick which changes if it can work or not. Mods can also change the active state of almost any entity which changes if it will work that tick or not.

Which is why I suggest making a 1 second battery in every single item. The actual calculation of consumption and generation wont change, but the period from generation to delivery is.

IE.
In any tick, it calculates the power generated by all power sources, and then calculates all power needed by all entities. In the following tick calculates the same, but while summing the power needed it also limits the productivity if power generated < power needed. (At least that's how I would implement it). It may also be implemented that it has to do double processing and apply the productivity in the same update tick, but that would be extremely slow and it would be very visible in the UPS at <100% power, I haven't observed that so I doubt its implemented like that.

In the 60 tick buffer scenario, we maintain 4 global variables, production and consumption, periodProduction and periodConsumption. In any given tick, you update the two first if an entity changed power usage or productivity and at the end add the value to the period variables. In the 60th tick, you calculate the productivity based on max(1, periodProduction/periodConsumption) and in the following 60 ticks that's what is used.

For normal gameplay where your power generation exceeds consumption you wont notice any difference. When consumption is too high, you will see a 1 second update in electricity display. IMHO that's actually a good thing, since right now you don't actually get any real value out of it flickering at 60 fps.

[Rseding91]

This doesn't even take into account that the logistics network and robot pathing is probably vastly more expensive than a simple inserter movement.

Robots don't do any path finding which is what makes them so performant compared to other methods of moving items.

[Engimage]

About turning off rendering when tabbed out
There is a downside. When you "tab in" you have to complete "initial render" before the game runs smooth after this. In Factorio tabbing in/out is smooth and does not require this.
I think you should at least make this an option cause as a personal preference I don't want to have this delay and want to tab seamlessly.

[Rseding91]

About turning off rendering when tabbed out
There is a downside. When you "tab in" you have to complete "initial render" before the game runs smooth after this. In Factorio tabbing in/out is smooth and does not require this.
I think you should at least make this an option cause as a personal preference I don't want to have this delay and want to tab seamlessly.

"Disabling rendering" is just "don't run the render code" there's no switch-in logic that has to happen - it's a simple bool switch - so there's no wait time to start rendering again.

[mrvn]

Roboports, inserters, radars, and mining drills have logic to do each tick which is why they're active.

• Roboports consume power and when out of power disconnect from the logsitic network and will no longer dispatch robots.
• Inserters have no way to know if an item has been added to the world at the location they want to grab.
• Radars consume power and scan chunks around them + generate chunks in the distance as they scan.
• Mining drills can have fluid + consume power and apply mining progress each tick.

That's all working as intended.

Regarding #1 and #2: those checks already account for virtually all of the time spent in those areas. Once the check is done it's almost free to have the inserter or robot just do the work instead of saying "nah not yet" - it wouldn't gain anything and probably would slow the normal simulation down from all the extra checks.

In virtually all cases it's not acceptable to not be accurate when it comes to power consumption which is why things work on a per-tick basis. Also mods can adjust power in any entity at any tick which changes if it can work or not. Mods can also change the active state of almost any entity which changes if it will work that tick or not.

None of these things if they magically took zero CPU time would enable any significant improvement in game performance. You might get an additional 5-10% in the extreme scenarios but you're not going to be able to double your factory size. The slowest 4 parts of the game are still: biters, belts, robots, and inserters. Simply because of the numbers of them that exist at once on a given map.

Turning off rendering when the game is minimized sounds like a decent idea. I don't know why you'd leave the game in that state but it's a logical thing to do and I don't think there's anything limiting us from doing it.

Sorry, but that is just short sighted.

Roboports consume power every tick, so does everything else. But you do know how much and you do know when it changes, e.g. a bot arrives for charging. Inbetween those events the power consumption is constant. So you can compute the power consumption once and then only update it on change.

Inserters don't know when an items is added to the game? Why not? Seems like placing an item happens less often than you have inserters? So why not have the place function check for and wake up inserters? Don't you do that with chests and belts already?

Radars? Afaik they consume an absolute constant amount of power. They are always on. Totally predictable. And they do not scan a new chunk every second. You know how long the scan progress takes. Let it wake up when that reaches 100% and then do the scan thing. No need to check every tick if maybe it has reached 100%.

Mining drills also behave predictable. When they have their fluid and the ore isn't empty they consume a constant amount of power. When they don't or are blocked they also consume a constant amount of power. You know when the state changes.

So don't have the entities be short sighted and decide their power consumption every tick. Have them look ahead into the future and say how much power they need for how many ticks before things will change or trigger a consumption update if an event happens. As long as power supply can meet demand all of this should be trivial to pre-compute. The drawback would be that UPS would fall when you have a brownout. Because then power availability would change every tick (because some inserter will start or stop somewhere on the map every tick) leading to a change in the predicted behaviour every tick.

Then again I wouldn't mind if entities would charge till they have full power and then work till they have none left. I think that would actually be preferable, at least for inserters. As is during a brownout inserters will frequently try to pickup an item from a belt and miss because they are too slow at 50% power. If the inserter waited till it is fully charged before trying to pick up an item then it would succeed and not waste energy on the attempt.

[Rseding91]

And how would you propose the energy statistics work in this scenario? Because they would become completely useless with any of the changes you describe.

When I say mining drills can have fluid (as can assembling machines and furnaces) that means they can't ever sleep. Fluid flows by updating the entity and if you don't update it - it won't flow.

There's no "wake up inserters when an item is created in the world" because there's no sleeping list for an inserter to sleep in when there's no entity to pick up from. The entity is what provides the sleep mechanic and without it it doesn't work. It's like saying "every time you deliver a letter let everyone know who's interested that it was delivered". Not to a
specific house - just in general when one is delivered. First: who is "everyone who's interested", second where will that list be maintained so if someone decides they aren't interested they can be removed from that list?

It's impractical - some of your ideas are good but the majority don't work and they don't work for lengthy reasons that you don't understand because you haven't sat down and looked over the full complexity that is Factorios inner workings.

We can not just shut off an energy consuming or producing entity for some ticks and call it "good enough" - it completely breaks things like power provided = work done, energy consumption/production stats, power switches, circuit networks, logistic networks, fluid flow, and more.

[Rseding91]

Also I like #9 so I changed that for 0.16.

[mrvn]

And how would you propose the energy statistics work in this scenario? Because they would become completely useless with any of the changes you describe.

Instead of summing up all energy consumption each turn from scratch you remember the total amount consumed. Then whenever an entity changes it's energy consumption it subtracts the old value and adds the new value to the total. Voila, you have an accurate energy consumption value for every tick without every entity being alive every tick.

When I say mining drills can have fluid (as can assembling machines and furnaces) that means they can't ever sleep. Fluid flows by updating the entity and if you don't update it - it won't flow.

Fluids might need this. The way they are they are way to dynamic to predict. Downright chaotic. I even wonder if you can setup a pipe system that has standing waves in it.

There's no "wake up inserters when an item is created in the world" because there's no sleeping list for an inserter to sleep in when there's no entity to pick up from. The entity is what provides the sleep mechanic and without it it doesn't work. It's like saying "every time you deliver a letter let everyone know who's interested that it was delivered". Not to a
specific house - just in general when one is delivered. First: who is "everyone who's interested", second where will that list be maintained so if someone decides they aren't interested they can be removed from that list?

If the inserter picks up from a belt then it has an entity. If it picks up from a chest then it has an entity. If it picks up from an assembler then it has an entity. It seems to always have an entity except when it picks up from the map directly.

Now I totally understand why not every single tile in the map is an entity. But there aren't that many inserters that pick up from the map. Why not add a invisible dummy entity for the pickup point of an inserter? That way an inserter would always pick up from an entity and has a sleeping list. Wouldn't that even make things simpler?

It's impractical - some of your ideas are good but the majority don't work and they don't work for lengthy reasons that you don't understand because you haven't sat down and looked over the full complexity that is Factorios inner workings.

We can not just shut off an energy consuming or producing entity for some ticks and call it "good enough" - it completely breaks things like power provided = work done, energy consumption/production stats, power switches, circuit networks, logistic networks, fluid flow, and more.

You wouldn't shut it off. You just wouldn't spend time on it unless it changes.

It's like the decider combinator. I think you mentioned that the signal network only wakes up when the signals change. But the decider combinator gets an input signal and produces an output signal every tick. It doesn't shut off when the signal remains unchanged. It simply knows the output signal will also remain unchanged and not waste time computing it every tick.

[nljr]

Roboports consume power and when out of power disconnect from the logsitic network and will no longer dispatch robots.

This may not be working exactly right. When I add a new Roboport, even before I start supplying it with power, it causes robots to be dispatched from other roboports to the territory of the new one.

Should the network really be affected by a powerless roboport?

[Rseding91]

Roboports consume power and when out of power disconnect from the logsitic network and will no longer dispatch robots.

This may not be working exactly right. When I add a new Roboport, even before I start supplying it with power, it causes robots to be dispatched from other roboports to the territory of the new one.

Should the network really be affected by a powerless roboport?

New roboports have power to start with so the exact thing you describe works. You can see it on the right-pane tooltip when you build a new one.

[posila]

I can agree that this is a good idea to do, in fact, by default I assume ALL games turn off their graphics calculations when minimised.

That's quite interesting. I don't know if it is because I started to play games on DOS, where there was no such thing as multitasking, or my later console gaming "phase", but I never thought of things like the game should not render when minimized, or that I should be able to suspend the computer while the game is running without it crashing, or even lock the screen.

[Cine]

And how would you propose the energy statistics work in this scenario? Because they would become completely useless with any of the changes you describe..

I proposed 4 global variables, but having 4 * entity types instead wouldn't change the idea, nor materially change the speed gain. Since the 2 first variables contain the energy usage and production in the current tick, the energy statistics wouldn't change at all.

When I say mining drills can have fluid (as can assembling machines and furnaces) that means they can't ever sleep. Fluid flows by updating the entity and if you don't update it - it won't flow..

Aye, but as I state in 11. fluid dynamics in this game is horrible. Its too correct, which means its very slow and frankly its very hard to work with. Figuring out ahead of time when a pipe would become full is nearly impossible. It would both be much nicer on the CPU and easier to design if pipes were more similar to belts and had a fixed throughput per tick and fluids were quantized into integer sized bits. If I look at a belt, I can easily see if its moving at near optimal rate, if there are holes in the items I can see I can put more on, if its stopped I can see I need to consume more... With fluids, its telling me 89.2 water, which means what? A couple of pipes later its telling me its 87.7, still no clue why, how or what I need to do to improve the amount of water, nor do I have any clue how much water is getting to the destination.

There's no "wake up inserters when an item is created in the world" because there's no sleeping list for an inserter to sleep in when there's no entity to pick up from. The entity is what provides the sleep mechanic and without it it doesn't work. It's like saying "every time you deliver a letter let everyone know who's interested that it was delivered". Not to a
specific house - just in general when one is delivered. First: who is "everyone who's interested", second where will that list be maintained so if someone decides they aren't interested they can be removed from that list?.

7. was about the problem that inserters are always active when picking up from the ground. That really is a minor problem, and would most easily be solved by adding a dummy chest-like entity that can't actually hold more than whatever is dropped on it, and has no graphics. 1. is only applicable when you DO have an entity to draw from (The target doesn't matter), and that IS a major issue, as my calculation shows the result is that you often end up doing 3x the amount of computation for no changes in throughput.

It's impractical - some of your ideas are good but the majority don't work and they don't work for lengthy reasons that you don't understand because you haven't sat down and looked over the full complexity that is Factorios inner workings..

Optimizing for speed is very seldom practical. Every once in a while you end up with a simpler set of rules, because you were forced to think about how to do it fast. But often in order to get something fast, you have to special case alot of code that could otherwise be very simple and you end up with a ridiculous amount complex code.

You don't need to attack me for being ignorant of the inner workings of Factorio, I am simply trying to give you ideas and suggestions to improve your product, based on my experience playing Factorio and daily working with optimizing code. I do realize that often there are conflicting goals in development of a quality product.

We can not just shut off an energy consuming or producing entity for some ticks and call it "good enough" - it completely breaks things like power provided = work done, energy consumption/production stats, power switches, circuit networks, logistic networks, fluid flow, and more.

Noone has said anything about turning off the energy consumption or production. Simply that the calculations are done based on CHANGES in either, instead of recalculating them every single tick. You would still gain a huge amount if you were just maintaining the 4 global variables (only need the first 2, if doing it per tick) and only touching the individual entities when they change or when <100% power (You will just see a huge drop in UPS when power is low then, but again since thats NOT the common case, that shouldnt be what you optimize for)


PS. The energy statistics really could use some usability improvement in itself

[Engimage]

IMO fluid mechanics is too complex right now and does not need to be so. While most of other mechanics in the game are pretty obvious and you can easily visually understand them, fluids are a mystery for the most of Factorio players other from those stubborn to learn it through trial and error.

I would assume that in 90+% factories the complexity of calculations is not doing what it is intended to do - reaching the limits where it really matters. Even in megabases 90+% of pipes are just small interconnections where complex physics does not matter.

So in small scale the complexity does not matter and on big scale it needlessly hits performance too much.

So I am positively upvoting the need of fluid mechanics simplification along with making it more visually clear. Currently all you can understand is - the type of liquid, its amount in the pipe fragment and sometimes the direction of the flow. You just can't easily debug things such as why something is not working or am I reaching throughput limit or what the limit actually is etc.

I can't say that figuring out stuff by yourself is a boring thing. But in this particular case I think simplification is a better way to go.

[mrvn]

When I say mining drills can have fluid (as can assembling machines and furnaces) that means they can't ever sleep. Fluid flows by updating the entity and if you don't update it - it won't flow..

Aye, but as I state in 11. fluid dynamics in this game is horrible. Its too correct, which means its very slow and frankly its very hard to work with. Figuring out ahead of time when a pipe would become full is nearly impossible. It would both be much nicer on the CPU and easier to design if pipes were more similar to belts and had a fixed throughput per tick and fluids were quantized into integer sized bits. If I look at a belt, I can easily see if its moving at near optimal rate, if there are holes in the items I can see I can put more on, if its stopped I can see I need to consume more... With fluids, its telling me 89.2 water, which means what? A couple of pipes later its telling me its 87.7, still no clue why, how or what I need to do to improve the amount of water, nor do I have any clue how much water is getting to the destination.

This has bugged me a lot too. It is totally unclear how much fluid or gas flows through a pipe. Maybe when hovering over a pipe (or other fluid entity) it could show the amount transferred at each entry and exit point. Or at least the overall amount consumed (or spend for fluid producing entities) on the right.

Note: For entities with signals a throughput signal would be nice too.