Topic: Performance regression
Tibor |
Posted at: 2017-10-09, 20:26
I managed to get call profile from both savegames and it seems that the culprit is the issue I saw before: picking closest available ware for a requestor. If something (site usually) needs a ware, it goes over all free wares (or rather providers, that can be warehouse and flags usually) and with Astar algorithm looks for shortes path. This is the find_best_supply function:
On big maps and territories the time needed for finding paths can grow more than linearly, and this is probably what is going on here. The problem can be made worser when there is a lock on roads and there are many providers (flags with stuck wares) f.e. with wood on them. Some time ago I proposed a simplification that was that only N nearest (air distance) providers (flags, warehouses) would be considered for path finding. Risk of picking not nearest ware is quite small, while CPU saving can be big.. Edited: 2017-10-09, 20:42
Top Quote |
||||||||||||
SirVer |
Posted at: 2017-10-13, 18:29
I did a quick profile myself and agree with Tibors findings - Routing of wares takes the most time in PkK2. However I only see stuttering in debug builds - which is expected as the compiler has little chance to inline and the template heavy code around routing profits alot from inlining. In release builds, widelands takes < 20% cpu in PkK2 on my 2013 laptop. PkK, are you running a release game? Top Quote |
||||||||||||
Tibor |
Posted at: 2017-10-23, 21:21
I created a branch that implements my idea on speeding up the ware pairing: lp:~widelands-dev/widelands/ware_routing_speedup. SirVer said this is not critical, but still, perhaps somebody might find it useful. Edited: 2017-10-23, 21:27
Top Quote |
||||||||||||
SirVer |
Posted at: 2017-10-23, 22:34
That is not exactly what I said. What I said was that in Release mode I cannot measure a bottleneck in this code and I wondered if the regression can also be seen in Release mode or only in debug mode. Top Quote |
||||||||||||
Tibor |
Posted at: 2017-10-24, 06:43
I dont think it is a regression.... Top Quote |
||||||||||||
Tibor |
Posted at: 2017-10-30, 11:41
Maybe a command line switch activating my changes would be the best solution for all. I play right now on a big map an with a big territory and without this modification it is not playable... even 1x speed gives ~5 FPS and bad lags in UI Top Quote |
||||||||||||
SirVer |
Posted at: 2017-10-30, 19:34
Is this a debug build or a release build?
I am not fundamentally against merging your branch. I am sorry it that was the impression. I just feel that if the problem is not visible in a Release build, it is not a problem. Could you comment if you have the issues in Release as well and if not, why you are running a debug build? Top Quote |
||||||||||||
Tibor |
Posted at: 2017-10-30, 21:29
It is debug. I play with this just for practical reasons, if needed I can run the same binary it under gdb without re-compilation. I dont insist on merging it, because for my personal need I can anytime merge it into any branch I need. And my branch is not ready for merging, command line switch should be added first and some polishing in code done.. Top Quote |
||||||||||||
GunChleoc |
Posted at: 2018-02-17, 16:18
I tried the savegames from https://bugs.launchpad.net/widelands/+bug/1749653 on a release build, and this branch made a huge difference. The savegame that OP had a problem with is completely unusable in trunk on my machine, but will run quite normally with this branch. Busy indexing nil values Top Quote |
||||||||||||
Tibor |
Posted at: 2018-02-17, 18:14
sorry, what "this branch" means? Current trunk? Top Quote |