Page 1 of 2

Late game lag-substantial reduction?

Posted: Wed Aug 10, 2016 4:09 am
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?

Re: Late game lag-substantial reduction?

Posted: Thu Aug 11, 2016 11:40 pm
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!

Re: Late game lag-substantial reduction?

Posted: Fri Aug 12, 2016 1:30 pm
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:

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 5:37 am
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?

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 7:02 am
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:

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 9:11 am
by AndrewW
Bromstarzan wrote:Does FO use all available cores when computing turns? I guess so.
Each AI has it's own thread.

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 9:14 am
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.

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 12:58 pm
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.

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 7:29 pm
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.

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 7:37 pm
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.

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 8:05 pm
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...

Re: Late game lag-substantial reduction?

Posted: Sun Aug 14, 2016 10:02 pm
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

Re: Late game lag-substantial reduction?

Posted: Mon Aug 15, 2016 6:49 am
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.

Re: Late game lag-substantial reduction?

Posted: Mon Aug 15, 2016 7:48 am
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.

Re: Late game lag-substantial reduction?

Posted: Mon Aug 15, 2016 10:10 am
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.