Performance optimization - post your saves

[Rseding91]

jfyi Rseding91, using Microsoft's mimalloc implementation instead of glibc malloc has resulted in a 50% reduction in update time on a train-centric megabase save, from 7ms to 3.5ms.

Can you post the save file you're testing with? When I test mimalloc I only get a 6.5~% gain. This is on Windows though so it may already be using some variant of it internally for all I know.

[ptx0]

jfyi Rseding91, using Microsoft's mimalloc implementation instead of glibc malloc has resulted in a 50% reduction in update time on a train-centric megabase save, from 7ms to 3.5ms.

Can you post the save file you're testing with? When I test mimalloc I only get a 6.5~% gain. This is on Windows though so it may already be using some variant of it internally for all I know.

yes! i have a new internet plan with no more 50gb cap. I will post that later today.

[ptx0]

jfyi Rseding91, using Microsoft's mimalloc implementation instead of glibc malloc has resulted in a 50% reduction in update time on a train-centric megabase save, from 7ms to 3.5ms.

Can you post the save file you're testing with? When I test mimalloc I only get a 6.5~% gain. This is on Windows though so it may already be using some variant of it internally for all I know.

the important piece seems to be huge pages, which Windows does not support.

[ptx0]

https://drive.google.com/file/d/18y1aT9 ... sp=sharing

the improvements on an Intel CPU for this aren't as good as on Ryzen and that could be because Intel has a security mitigation where huge pages are split.

[AdamK]

This is my dump concerning trains and building track

With that base I got consistent 60FPS/UPS unless I'm building track. Base has a lot (3k+) trains and (500+ stops). On the bottom right there is construction of some structures set up, and while it is being constructed I see FPS/UPS drops down to 30 and sometimes 10.

Specs: i7-8086, RTX 3080, 32GB RAM.

[xykite]

I use a lot of unreachable train stops on purpose - it's the only way I know of to say "wait until next stop is available". From reading other posts, this appears to results in train repathing performance issues.

With this setup, if I mark one of my train grid squares for destruction then the game grinds to a halt for a couple of seconds. This seems excessive for a medium-sized map.

The main cause of the delay appears to be erasing the signals. What's happening is that each call to TrainManager::onSignalDestroyed calls TrainManager::recalculatePaths. So if you destroy multiple signals atomically (say, by marking a large area for deconstruction) then each train will get repathed once for each signal destroyed, i.e. a quadratic number of calls to Train::recalculatePath.

I don't claim to understand the train pathing system - is there a reason why a train might need to repath more than once per update? If not then this could be a perf bug. Otherwise the problem is my playstyle.

The attached save illustrates the issue: Each train is trying to reach the unreachable stop guarded by spidertron. When I mark the large area delimited by lights for destruction, I get 6720 calls to Train::recalculatePath (where 6720 == 40 trains * 168 signals) and a delay of ~500ms.

[Trific]

I suggest you use train limits instead of unreachable stops. I don't see a large drop in performance with that map, but I do have a fairly beefy computer, and there is a small drop in perf when marking one of the intersections for deconstruction. The drop goes away when I replace the unreachable stop with a reachable stop with a train limit of 0. The trains don't constantly try to repath to the station because there's no point to doing so if there is still no room at the station. Like the unreachable stop, trains will not skip a station that has no room.

[xykite]

I suggest you use train limits instead of unreachable stops. I don't see a large drop in performance with that map, but I do have a fairly beefy computer, and there is a small drop in perf when marking one of the intersections for deconstruction. The drop goes away when I replace the unreachable stop with a reachable stop with a train limit of 0. The trains don't constantly try to repath to the station because there's no point to doing so if there is still no room at the station. Like the unreachable stop, trains will not skip a station that has no room.

Thanks, that's helpful and is a much better way of doing it now we have train limits. I've checked that this does still cause the quadratic number of repaths, but the cost of each repath is now much lower.

Before and after stats:

beforeafter.png (858.3 KiB) Viewed 6611 times

[ptx0]

I don't claim to understand the train pathing system - is there a reason why a train might need to repath more than once per update? If not then this could be a perf bug. Otherwise the problem is my playstyle.

it's pretty annoying, considering when deconstructing it for robots, the performance impact is MUCH more reasonable.

[ptx0]

just wanted to state that trains with vehicle equipment grids have a huge performance penalty, a map with something like 1000 trains was consuming 7ms update time in CargoWagon, triggered PortableRoboportProvider::update unnecessarily - the grids on most trains are empty.

[Rseding91]

just wanted to state that trains with vehicle equipment grids have a huge performance penalty, a map with something like 1000 trains was consuming 7ms update time in CargoWagon, triggered PortableRoboportProvider::update unnecessarily - the grids on most trains are empty.

I would need a save file showing the slowdown. When I test that scenario; 1000 cargo wagons with equipment grids it takes 0.1 MS/tick.

[ptx0]

just wanted to state that trains with vehicle equipment grids have a huge performance penalty, a map with something like 1000 trains was consuming 7ms update time in CargoWagon, triggered PortableRoboportProvider::update unnecessarily - the grids on most trains are empty.

I would need a save file showing the slowdown. When I test that scenario; 1000 cargo wagons with equipment grids it takes 0.1 MS/tick.

i have 780 trains with 99 cargo wagons on each. it's based on the same save file I provided already.

https://drive.google.com/file/d/1JY5jXF ... sp=sharing

[xykite]

I use a lot of unreachable train stops on purpose - it's the only way I know of to say "wait until next stop is available". From reading other posts, this appears to results in train repathing performance issues.

With this setup, if I mark one of my train grid squares for destruction then the game grinds to a halt for a couple of seconds. This seems excessive for a medium-sized map.

The main cause of the delay appears to be erasing the signals. What's happening is that each call to TrainManager::onSignalDestroyed calls TrainManager::recalculatePaths. So if you destroy multiple signals atomically (say, by marking a large area for deconstruction) then each train will get repathed once for each signal destroyed, i.e. a quadratic number of calls to Train::recalculatePath.

I don't claim to understand the train pathing system - is there a reason why a train might need to repath more than once per update? If not then this could be a perf bug. Otherwise the problem is my playstyle.

The attached save illustrates the issue: Each train is trying to reach the unreachable stop guarded by spidertron. When I mark the large area delimited by lights for destruction, I get 6720 calls to Train::recalculatePath (where 6720 == 40 trains * 168 signals) and a delay of ~500ms.

Out of curiosity I tried reducing the quadratic number of repaths dynamically. After a couple of attempts that caused the game to fail on assertions, I came up with this: instrument Train::requestPath to return NULL each time it's called from within CommonActionHandler::deconstruct. If we make any of these skips then make a extra call to TrainManager::recalculatePaths at the end of CommonActionHandler::deconstruct, this time letting Train::requestPath run as normal. This means that Train::requestPath is only called at most once per train per update (within CommonActionHandler::deconstruct anyway).

This appears to give a fairly dramatic speed improvement in pathological cases. Obviously a) this clearly isn't the way to do it properly, and b) it's still very possible that the idea doesn't actually work at all and I'm breaking something important.

[1leahcim]

I have a train based megabase with a large amount of trains and launching a lot of rockets and running a real LOW ups on my new pc. I have completed the first version and would like a breakdown on how my ups is being spent. This base will run in vanilla other then the use of creative power and void chests. I have taken saves running different production voided.

I have 3000 trains.
384 belts of green circuit production
70 belts of red circuit production
12 belts of blue circuit production

30~32 rockets per minute
24k LDS,RCU,RF+SL


I can run the reds blues and greens "hot" at about 25-30 ups. but launching rockets drops me to about 13 ups.

https://drive.google.com/drive/folders/ ... sp=sharing

[ptx0]

I have 3000 trains.
384 belts of green circuit production
70 belts of red circuit production
12 belts of blue circuit production

30~32 rockets per minute
24k LDS,RCU,RF+SL

"built too much" - you just gave the breakdown of how it's being spent. belts, inserters, and assembling machines.

and locomotives. 3000 trains is a lot. my map with 1000 trains has them using almost 6ms of update time.

infinity chests are also extremely expensive.. make it without them

[1leahcim]

"built too much" - you just gave the breakdown of how it's being spent. belts, inserters, and assembling machines.

I am more wondering if there is issues with the distance the trains need to travel or if the amount of rails and signals are taking a lot. I think I can reduce my trains by about %60 without changing my production by upgrading from 8 and 12 belt 1 - 4 trains to 16 belt stations.

[ptx0]

"built too much" - you just gave the breakdown of how it's being spent. belts, inserters, and assembling machines.

I am more wondering if there is issues with the distance the trains need to travel or if the amount of rails and signals are taking a lot. I think I can reduce my trains by about %60 without changing my production by upgrading from 8 and 12 belt 1 - 4 trains to 16 belt stations.

hit F4 and in the Debug tab select show-time-usage and then hit F5 and see the time taken by the train pathfinder. if it's high, your rail segment count is too much. if it's in "Trains", that's likely just due to the sheer number - long trains perform better than slow trains. cargo wagons are cheaper than locomotives.

belt balancers are pretty evil too. if you just design to never need them you'll be further ahead.

[Napoletana]

I'm running into some performance issues on my computer (stock 2950x | RTX3090) on a nearly vanilla game (squeekthrough, nanobots and autodeconstruct). The savegame is in this link;

https://we.tl/t-oLVC2rhWa6

I've expanded a little since this screenshot was taken, but right now I'm facing about 30 UPS on my machine.


I decided to create a linux VM on an i3 9100 and run factorio headless as a server. I uploaded my savegame there and I had to reduce the CPU power of the VM to about 30% as my PC couldn't catch up and join.

I ran a few benchmarks to see if the CPU or GPU was underperforming, but they are both within normal comparative benchmark results. Am I doing something wrong in my base?

[jodokus31]

I had a look. (Shortcut F4: show-time-usage).

Entity update is quite high.
I tested to kill all biters, which improved the performance quite a bit:
https://wiki.factorio.com/Console
section Kill all enemies

There are probably more possibilities to reduce entity update.
Circuit Network is also quite high with 2 ms

[1leahcim]

hit F4 and in the Debug tab select show-time-usage and then hit F5 and see the time taken by the train pathfinder. if it's high, your rail segment count is too much. if it's in "Trains", that's likely just due to the sheer number - long trains perform better than slow trains. cargo wagons are cheaper than locomotives.

I removed 2 or 3 mods and I went from 13ups to 18ups.

but it does look like trains takes up more then train pathfinder.