Late game lag-substantial reduction?

Describe your experience with the latest version of FreeOrion to help us improve it.

Moderator: Oberlus

Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Message
Author
User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Late game lag-substantial reduction?

#1 Post by MatGB »

I'm playing a big game, one of the largest maps I've played for years, and set on Medium planets, not Low.

It's turn 220, my fleet now contains 199 vessels and I've over 200 colonies and outposts. A year ago, those numbers would've seen me scrapping ships frantically and considering whether to end the game because lag was making it almost unplayable. I'm not now. This is really cool.

A chunk of recent changes, including the way supply propagation is worked out/displayed and changes to population scripts making them substantially more efficient appears to have had, for me, a substantial reduction in lag—manual focus changes and queuing of production items still has lag, but at nowhere near the "go and make a coffee" level it was, until recently, causing at this stage in a game.

I'm on a quad-core Linux box with passable integrated graphics, I'm curious if others have noticed improvements on their systems, especially in the last few weeks, and/or if there are some systems where t hasn't really made any difference?

I also want to specifically thank our relatively new contributors, LGM-Doyle and Dbenage-CX, it's largely (but not exclusively—Geoff specifically suggested some of the changes would help) been their work that's made these improvements and as lag has been something that virtually everyone (especially me) has been complaining about for years such a significant improvement is definitely worth commenting on. Thanks guys.

So, on an unrelated note, I'm in the mood to play a really big map with challenging settings that I've not been able to do for ages. I'm thinking probably a large spiral, what do people think would make the most challenging setup (for a player) on a really big galaxy?
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Doc Tectonic
Krill Swarm
Posts: 10
Joined: Mon Aug 08, 2016 3:24 am

Re: Late game lag-substantial reduction?

#2 Post by Doc Tectonic »

I mostly play on a wimpy little laptop, and the latest test builds are definitely better than the official v0.4.5 release from 2015-09-01, which I was playing until just recently. The UI still starts to get a bit laggy in late game, but it's not as bad as it was. Good work!

User avatar
Bromstarzan
Dyson Forest
Posts: 206
Joined: Sun Feb 28, 2016 9:56 pm
Location: Sweden

Re: Late game lag-substantial reduction?

#3 Post by Bromstarzan »

Good to hear that computing time has improved, indeed.
I'd say "clusters" all the way - very hard to anticipate where the game is going! :mrgreen:
| i7 7700K [email protected] | GTX 1080 Ti | RAM: 32GB | PSU: 750w | W10 x64 | 2xAcer1920x1080 |

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Late game lag-substantial reduction?

#4 Post by MatGB »

K, by the end of the game (see Timed that one nicely for a screenshot), production was at 30K with a 38K target, I had 3042 planets and 331 ships.

Lag was at a point that it was annoying me, but I've played on with much higher lag levels on much smaller games.

The problem isn't solved, but it is reduced so much that it's no longer something I'd consider game-breaking at higher levels. This is a really good thing.

Of course, I now wonder where else we can find efficiencies in the scripts to improve performance. I'm especially wondering if there's any way we can improve ship/fleet handling, as killing all my ships after victory did speed things up a bit the next turn.

However, that sort of thing is beyond me and it's mostly guesswork—any ideas from the better coders?
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Bromstarzan
Dyson Forest
Posts: 206
Joined: Sun Feb 28, 2016 9:56 pm
Location: Sweden

Re: Late game lag-substantial reduction?

#5 Post by Bromstarzan »

Thanks for the report!

Does FO use all available cores when computing turns? I guess so.
A fast computer does help, but of course the aim should be to make FO playable on slower machines as well.

FYI, I have never considered the lag, not even at turn >500. However, I have only run 3 AI's at moderate difficulty and ca 150 systems. Ending turn takes ca 2-3 seconds.
Unless the code can be further optimized, the solution is perhaps to limit the number of AI? In this case, "less is more" :mrgreen:
| i7 7700K [email protected] | GTX 1080 Ti | RAM: 32GB | PSU: 750w | W10 x64 | 2xAcer1920x1080 |

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Late game lag-substantial reduction?

#6 Post by AndrewW »

Bromstarzan wrote:Does FO use all available cores when computing turns? I guess so.
Each AI has it's own thread.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Late game lag-substantial reduction?

#7 Post by Vezzra »

Bromstarzan wrote:Does FO use all available cores when computing turns?
Unless you count the AI client processes (see Andrews reply), nope. The server (which is the component that does the turn processing) is essentially single-threaded.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Late game lag-substantial reduction?

#8 Post by Geoff the Medio »

Vezzra wrote:The server (which is the component that does the turn processing) is essentially single-threaded.
Effects processing on the server (and clients) is multi-threaded by default. Whether this makes any substantial difference to processing times, I'm not sure.

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: Late game lag-substantial reduction?

#9 Post by LGM-Doyle »

MatGB your post pushed me over the hurdle to finish PR #863, to address lag when splitting large fleets.

Since you asked to help, I will make two requests.

The first is, if you still have the saved game handy, can you do a before and after test of PR #863. Load the save game and measure the time to merge and split your largest fleet. That would give another data point about how the PR performs.

The second is do you have any specific examples of performance problems from late in the large game.

Everything getting faster after you destroy all of your ships is not concrete enough for me to address.

An example might clarify what I mean.

When I started work on PR #863, I started with one fleet button that took a long time to split. I wrote increasing sophisticated profiling code around that one event, until I figured out exactly why it was slow. Then I fixed what I could.

Thanks in advance.

p.s. Edited to fix the PR number.
Last edited by LGM-Doyle on Sun Aug 14, 2016 8:27 pm, edited 1 time in total.

defaultuser
Juggernaut
Posts: 854
Joined: Wed Aug 26, 2015 6:15 pm

Re: Late game lag-substantial reduction?

#10 Post by defaultuser »

AndrewW wrote:
Bromstarzan wrote:Does FO use all available cores when computing turns? I guess so.
Each AI has it's own thread.
I thought they were separate processes.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Late game lag-substantial reduction?

#11 Post by Vezzra »

LGM-Doyle wrote:MatGB your post pushed me over the hurdle to finish PR #862, to address lag when splitting large fleets.
Um, I assume you actually mean PR#863 here (and the other two links too)? I was a bit confused when I clicked that link and issue #862 opened, which is about something entirely different...

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Late game lag-substantial reduction?

#12 Post by MatGB »

LGM-Doyle wrote:MatGB your post pushed me over the hurdle to finish PR #863, to address lag when splitting large fleets.

Since you asked to help, I will make two requests.

The first is, if you still have the saved game handy, can you do a before and after test of PR #863. Load the save game and measure the time to merge and split your largest fleet. That would give another data point about how the PR performs.
Merge and split before and after wasn't that bad on a fresh load up—I've noticed in the past that lag gets worse as you play multiple turn, and it always reduces if you load a frech game.

However, there was a noticeable improvement. Merging and splitting the doomstack of ~240 ships in orbit around the Experimentors took just less than a second on my previous compile, having compiled that branch it was almost lag free, so fast I couldn't time it manually.

Having said that, I noted yesterday when scrapping the fleets that the fleet-scrapping time had been substantially reduced as well, it used to take an age to scrap a large fleet but it was a negligible time for the large fleets using Master. I have no idea when this improved or why but whatever did it is also welcome (I've been in the habit recently of just finishing a game when I know I've won, so fleet scrapping has been something I've done less of).
The second is do you have any specific examples of performance problems from late in the large game.

Everything getting faster after you destroy all of your ships is not concrete enough for me to address.
Specifically, things like queuing a production item, especially a ship, and changing a build order to increase the number of ships or to add repeats, always substantially laggy, and still a problem.

Also, changing focus with the sidepanel open—using the Objects menu context option for multiple changes is always very quick, unless the sidepanel is open with one of the changing planets displayed, at which point it slows to a substantial crawl.

Queuing a large number of buildings on different planets via Objects can take a LONG time to process—substantially faster than going into each system and doing it manually but the lag is still noticeable and into the several seconds point: I normally only do this for terraform or Gaia transform orders (in this game I had virtually every planet turned into a paradise because I had the resources).

Being able to queue from Objects is brilliant, and overall it's substantially faster, but if you try to queue multiple planets at once (I did batches of about 20 planets) then it takes awhile.

I've uploaded a savegame as an issue on my personal git profile, there's almost certainly a better way to do it but...
Large savegame double victory with huge fleet · Issue #1 · MatGB/FO-shared-files
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: Late game lag-substantial reduction?

#13 Post by LGM-Doyle »

MatGB thanks for the testing reports.

Do you build for Release or Debug?

Thanks for the observation about the sidepanel greatly slowing down the game. I had not noticed that.

That is specific enough for me to replicate.

I will not guarantee an improvement, but I will look at the issue.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Late game lag-substantial reduction?

#14 Post by MatGB »

I think I build for Release, but I never intentionally changed or set the settings and am not sure I'd know how, I was walked through how to compile on Linux just after I got this box on here and haven't done anything to change setup since then.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Late game lag-substantial reduction?

#15 Post by Vezzra »

Looking at the cmake files indicate that the default build type is release, so unless you set it to debug (and your answer implies you did not) you get a release build.

Post Reply