SLOW Performance Issues: post here to report
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
Re: SLOW Performance Issues: post here to report
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
Re: SLOW Performance Issues: post here to report
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
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
- Posts: 5
- Joined: June 3rd, 2025, 12:54 am
Re: SLOW Performance Issues: post here to report
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.
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.
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.
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.
- Attachments
-
The Battle for Wesnoth_buildinfo.txt- (1.63 KiB) Downloaded 32 times
-
-
TDG-Long Live the Queen Turn 163e.gz- (858.22 KiB) Downloaded 32 times
-
- TDG-Long Live the Queen Turn 58.gz
- (405.25 KiB) Downloaded 26 times
-
dank_knight
- Posts: 5
- Joined: June 3rd, 2025, 12:54 am
Re: SLOW Performance Issues: post here to report
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.
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.
Re: SLOW Performance Issues: post here to report
Summary: slowness introduced in 1.19.6, tracked to 12fa8f28447e21e7522dba608034a08b984c05ac
To reproduce from attached save game: end turn 7. The AI will (long) pause before its next move, and (less long) between moves.
Description: seems to occur when there are many combat options for the AI to choose from. Before the affected version, the decision time is not noticeable. From 12fa8f up to 1.19.21, the AI can take from 10s to several minutes to move each unit.
Not special to this map - seen this across multiple campaigns.
The delay becomes negligible on reducing the size of the window a lot (from ~2000x1200 to 800x600). Changing the zoom level and other display settings has no noticeable effect.
The slowness affects the rendering - most obvious when looking at the village flags, or windmills, which stutter/skip.
OS: Debian 12
Wesnoth version: 12fa8f28447e21e7522dba608034a08b984c05ac (with d4de3f15b cherry-picked to fix a fpe) onwards, confirmed up to 1.19.21, English (US), also confirmed with French
Build information (12fa8f):
The Battle for Wesnoth version 1.19.5+dev x86_64
Running on Debian GNU/Linux 12 (bookworm) x86_64
Distribution channel: Default
Libraries
=========
Boost: 1.74
Lua: 5.4.6
OpenSSL/libcrypto: 3.0.0r-dev (runtime 3.0.0r-dev)
libcurl: 7.88.1 (runtime 7.88.1)
Cairo: 1.16.0 (runtime 1.16.0)
Pango: 1.50.12 (runtime 1.50.12)
SDL: 2.26.5 (runtime 2.26.5)
SDL_image: 2.6.3 (runtime 2.6.3)
SDL_mixer: 2.6.2 (runtime 2.6.2)
Features
========
Lua console completion: yes
D-Bus notifications back end: yes
Installed add-ons
=================
No add-ons installed.
To reproduce from attached save game: end turn 7. The AI will (long) pause before its next move, and (less long) between moves.
Description: seems to occur when there are many combat options for the AI to choose from. Before the affected version, the decision time is not noticeable. From 12fa8f up to 1.19.21, the AI can take from 10s to several minutes to move each unit.
Not special to this map - seen this across multiple campaigns.
The delay becomes negligible on reducing the size of the window a lot (from ~2000x1200 to 800x600). Changing the zoom level and other display settings has no noticeable effect.
The slowness affects the rendering - most obvious when looking at the village flags, or windmills, which stutter/skip.
OS: Debian 12
Wesnoth version: 12fa8f28447e21e7522dba608034a08b984c05ac (with d4de3f15b cherry-picked to fix a fpe) onwards, confirmed up to 1.19.21, English (US), also confirmed with French
Build information (12fa8f):
The Battle for Wesnoth version 1.19.5+dev x86_64
Running on Debian GNU/Linux 12 (bookworm) x86_64
Distribution channel: Default
Libraries
=========
Boost: 1.74
Lua: 5.4.6
OpenSSL/libcrypto: 3.0.0r-dev (runtime 3.0.0r-dev)
libcurl: 7.88.1 (runtime 7.88.1)
Cairo: 1.16.0 (runtime 1.16.0)
Pango: 1.50.12 (runtime 1.50.12)
SDL: 2.26.5 (runtime 2.26.5)
SDL_image: 2.6.3 (runtime 2.6.3)
SDL_mixer: 2.6.2 (runtime 2.6.2)
Features
========
Lua console completion: yes
D-Bus notifications back end: yes
Installed add-ons
=================
No add-ons installed.
- Attachments
-
- SotA-Blackwater-Auto-Save7.gz
- (55.28 KiB) Downloaded 7 times
-
- logs.tgz
- (58.5 KiB) Downloaded 5 times
Re: SLOW Performance Issues: post here to report
Thanks for tracking this down to a single commit. Unfortunately these things are often difficult to reproduce with the average developer machine. Do you have different examples where the slow down is even more noticeable? The example save does not seem to have that many combat options for the AI.Guida wrote: March 15th, 2026, 8:26 pm Summary: slowness introduced in 1.19.6, tracked to 12fa8f28447e21e7522dba608034a08b984c05ac
To reproduce from attached save game: end turn 7. The AI will (long) pause before its next move, and (less long) between moves.
Description: seems to occur when there are many combat options for the AI to choose from. Before the affected version, the decision time is not noticeable. From 12fa8f up to 1.19.21, the AI can take from 10s to several minutes to move each unit.
You're comparing 1.19.5 or a build of commit cd3e8d7652c (parent of 12fa8f) to 12fa8f or later, yes?
Can you post some specs of your computer? Do you see wesnoth using 100% CPU (on one core at least) when the slow down occurs?
"If gameplay requires it, they can be made to live on Venus." -- scott
Re: SLOW Performance Issues: post here to report
I tried compiling this too (on a machine that's more than a decade old) and I didn't notice any delays.Guida wrote: March 15th, 2026, 8:26 pm To reproduce from attached save game: end turn 7. The AI will (long) pause before its next move, and (less long) between moves.
I'm wondering if there's something about the way it was compiled that is triggering the issue...
- What compiler are you using - gcc or clang? What version?
- Are you using a debug or release build?
- Are you using cmake or scons?
- Also, do you have any non-default preferences set? (In particular, are you running with "Animate water" enabled or disabled?)
Re: SLOW Performance Issues: post here to report
- What compiler are you using - gcc or clang? What version?
- Are you using a debug or release build?
- Are you using cmake or scons?
- Also, do you have any non-default preferences set? (In particular, are you running with "Animate water" enabled or disabled?)
- Compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0
- Tried release+debug builds, same result
- cmake
- Clean install with default preferences only - "Animate water" is enabled. I've been through all the display preferences in the in-game menu and found no significant differences in performance
The one I remember particularly is the first scenario in the new HttT campaign - the delays start around turn 3 onwards, as several AI sides get into close combat with other AI sides.Do you have different examples where the slow down is even more noticeable? The example save does not seem to have that many combat options for the AI.
But it's consistent - no delay at the start when sides are far apart, and delays become noticeable when there are many combat options (could be something else, but it seems consistently linked to this).
The save I attached is an uncomplicated situation where the delay is consistently noticeable.
Yes, except for the cherry-pick of d4de3f15b for both (otherwise Wesnoth terminates with an fpe on start).You're comparing 1.19.5 or a build of commit cd3e8d7652c (parent of 12fa8f) to 12fa8f or later, yes?
Fairly new laptop. It's had graphics lags for basic things in the past, but nothing after fixing an overheating issue. It's running Xen, and I was compiling/running on a clean Debian 12 VM. Changing CPU/mem allocation and limiting to a single core didn't change anything, and little else was running at the same time.
The CPU spikes to 90%+ during a delay and then reduces during move/fight animations.
One new observation - often but not always, it looks like I can "force" the move, by clicking/moving the viewport away from the busy area, and then it responds straight away.
I thought it might be one of these. Thanks for taking a look.Unfortunately these things are often difficult to reproduce with the average developer machine.
Re: SLOW Performance Issues: post here to report
Can you reproduce the issue on the host as well? It sounds like it might be related to virtualization.Guida wrote: March 23rd, 2026, 12:47 am Fairly new laptop. It's had graphics lags for basic things in the past, but nothing after fixing an overheating issue. It's running Xen, and I was compiling/running on a clean Debian 12 VM. Changing CPU/mem allocation and limiting to a single core didn't change anything, and little else was running at the same time.
"If gameplay requires it, they can be made to live on Venus." -- scott
Re: SLOW Performance Issues: post here to report
I compiled the latest version while running a Debian 12 live CD on the same host and could not reproduce the issue, so I'll assume it's the virtualization. I expect that's going to be more of a niche rabbit-hole than I was bargaining for, so if no one else is seeing this then I'll move on. Appreciate the guidance.Soliton wrote: March 23rd, 2026, 2:51 pm Can you reproduce the issue on the host as well? It sounds like it might be related to virtualization.