SLOW Performance Issues: post here to report

[Scaramush]

online-lobby has become extremely laggy for me since 1.18. sometimes the ping between mouse-scroll and reaction is like 5-7 seconds. not really hoping to find a solution, as it's probably due to old laptop, just complaining xD

[elj40]

This report isn't on gameplay but about unzipping the game.

I am using windows 11 and the default unzipper to extract the files. In my experience it is able to unzip large files very quickly, but slows down a lot when it needs to extract a lot of smaller files (such as all the sprites).

Maybe creating a sprite atlas could help with this?
Small suggestion for a small problem

[dank_knight]

May just be an edge case of "you are not meant to fight like a band of indomitable Gauls sustained by druids against a quantity of troops that would feel at home next to a Roman legion" in the final scenario of The Deceivers Gambit II - but it's in development so reporting the slowness that develops between turns. Maybe there's an algorithmic simplification that is possible

Problem:
In version 1.19.11 & 1.19.12 of the game after a varying number of turns in the final scenario of The Deceiver's Gambit II it slows/freezes between turns - the variation may be due to number of units in opposing army varying with the number of leaders one kills before retreating to a defensible corner. I don't think it has ever actually crashed but waiting 5 to 20+ minutes per turn or similar for the AI to move the opposing troops is quite a freeze. There's also an observable variation between turns when there is a clear incentive for AI to advance & attack (lower CPU usage and less freezing) compared to turns where the AI frontline stays static (see patterns in performance metrics). As a step by step to reproduce issue: open the attached save file that has 163e in name and immediately end the turn - the AI should have an easy time of it (the small spike seen in attached CPU graph) then one of the subsequent turns should see the long delays and maxed out CPU core (alternating between the cores) seen as the second prolonged spike, that manifests as a long multicolored bar, in the CPU graph.

System details: Fedora Linux Workstation 42 x86_64, Wesnoth version 1.19.11 & 1.19.12 (details in attached buildinfo file), 16GB of DDR3 RAM, quad core i5 4th Gen CPU with 4 threads running at 3.2GHz. So rather elderly system but not that underpowered I'd think.

Performance metrics: Using System Monitor A) the RAM usage is fine given there is 16GB RAM (only a few GB used - no RAM usage spike) b) there are 3 distinct patterns I have seen re: movement of opposing army and the CPU usage. In the attached CPU/RAM usage graphs from System Monitor you are seeing a spike due to a Pattern 3 turn (high but less than 99% CPU usage and turn relatively swiftly completed) followed by a long Pattern 1 max out of various CPU cores. I may have had some other open programs so you might get lower RAM usage than me. Without the computer producing the usage graph (if one switches away from the resources tab of System Monitor) the usage would just be a single core maxed out - in the long bar produced by alternating cores the little spike above the bar is produced by switching to System Monitor window so other cores have to do a little work to render the graph).
The patters are as follows.

• Pattern 1: the freeze/slowness is associated with one core of the CPU being maxed out 99% or more - but which core alternates as time goes by. Long periods of no movement of enemy troops seen. Eventually resolves.
  Pattern 2: still a very long wait between turns, and possibly quite a wait between seeing any movement of opposing troops - but the CPU cores do not max out - they might reach 80% or 90% on an alternating basis but there is a sustained difference in contrast to "pattern of alternating 99% usage on one core of the four at a time". Still long wait between turns.
  Pattern 3: seen with remaining troops backed into corner when a line of opposing troops was eliminated and it was daytime the opposing troops would rapidly be advanced and the movement of the troops behind them would cascade. In this pattern the time between turns was much better - mostly depending on the cascading movement being completed - on the overview mini-map the movement is like the cascade of a field of dominos falling over.

Other observations: doing a replay so I eliminated all leaders in actual forts (not part of the column on the road) postpones the point at which the freezing was very noticeable & regular (maybe from turn 40 something to turn 90 something). As you might infer the save with 163e in name is from that replay!

There was this line in the log "info engine/enemies: team 8 found same team name [eldred] in team 10" that seems notable. If there is many as 10 teams involved and the calculations have to look at all the other teams before moving that might account for the long periods of no movement. I have "skip AI moves" enabled in settings and an acceleration factor of 3 for accelerated speed.

The key to surviving to 40+ turns without getting wiped out when you have only a dozen units or less is using the Blizzard spell so that opposing troops are slowed by traversing snow - and then going to the very defensible upper right corner of the map and recuperating with multiple healers.

Save files are attached.
As noted: end the turn for 163e and you should see AI advance followed by a relatively rapid transition back to it being your turn (pattern 3) but keep playing and pattern 1 will become evident.
The turn 58 save is with different troops and different leaders (western leader(s) still alive) showing the issue is not with one particular set of leaders or troops. The noticeable lag as turns goes on should be reproducible by 100 turn mark whatever your CPU. https://www.cpubenchmark.net single thread rating for the CPU I am using here is ~2k and for a much more recent i5-12400 is ~3.5k - so newer is clearly better but not so much better that I'd predict a newer CPU eliminating the wait. Also this kind of freeze/slowdown not so very obvious on other campaigns or even scenarios in this campaign.

Given the number of teams and the number of opposing troops I wonder if this is a product of multiple teams having to survey the battlefield then calculate if there is a path forward for each unit, then whether the unit should advance. In programming terms using big O notation I think risk can be framed as O n squared situation (where n is number of teams or troops). I'm afraid I am not familiar enough with C++/Lua etc or the codebase to dive in and check/fix it. But maybe an experienced dev can see if that line of thought is on the right track.

In human logic by contrast I think if one had, in terms of your troops, many times the quantity compared to the opposing troops near the front line one could let a bit of a gap develop a few rows back from the frontline - as long as replacements can be brought to the ranks by the frontline as soon as the ratio of your troops vs opposing troops drops (i.e. if facing a dozen troops then having 4 dozen of yours nearby and replenishing them when that becomes a 3 to 1 ratio rather than 4 to 1 would be sufficient - whereas I think the product/outcome of the AI is "pack troops in as closely as possible" and a lot of CPU time used to keep calculating and recalculating how to achieve that packing).

Can dig up some logs if helpful and necessary - but hopefully the save files allow the issue to be reproduced easily.

[dank_knight]

Re: the Deceiver's Gambit II finale slowdown report above - an idea for an AI fix is to be found here viewtopic.php?p=698675#p698675 . I call it "marching mode" and in essence if the AI troops occupy much of the map and the opposing force is geographically constrained then divide the map into a combat area/frontline where the default AI applies and outside that have a "marching ground" area through which the AI should march the units towards the front in a very predictable pattern.
Easier to describe a "marching mode" than to program it of course - which is why I say in that post that an official statement on the slowdown, such as something in the official walkthrough, might be the way to go if the campaign is confirmed as mainline.

I also argue in that post - based on another finale completed with a defensive strategy - that folks might survive in the Deceiver's Gambit II finale long enough to be affected by the slowdown and do so often enough that the slowdown might not be that niche.