FreeOrion

Forums for the FreeOrion project
It is currently Sun Nov 19, 2017 4:51 am

All times are UTC




Post new topic Reply to topic  [ 46 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Aug 05, 2015 4:43 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3259
I have a completely different solution to the lag problem that creeps in after turn 250ish:

Try to always win by then ;-)

And yeah, whenever discussions get into higher end maths or more complex coding I tend to switch out and go find some basic addition style stuff that my elderly brain can still grok.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 4:51 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4374
Vezzra wrote:
Now, my math skills are quite humble, but AFAIK this means there is absolutely no way to get below n^2 behavior.
It means that the theoretical worst behavior is necessarily like that over some kind of time range, but it doesn't necessarily mean that our typical behavior necessarily has to be like with within the span of 500-1000 turns or something.

One of the big changes from a year or two ago was to make Conditions start out with appropriate smaller sets of objects to scan (like if we have a "System" Condition, instead of scanning all objects to see which objects are systems, we start off with a pre-processed set of Systems). I believe there are still a few more techniques that could be applied to bring some n^2 operations down to n log n (or N^3 down to n^2 log n), but I don't think those are actually our biggest issue.

I think the biggest issue has to do with cascading waves of ObjectChangedSignals in the MapWnd. Notice that the delay when you change the Focus on just a single planet in the SidePanel is very similar to the entire delay for changing the Focus on a whole set of planets via right-click in the ObjectsList Window. I rather suspect it is similar cascades of update signals, slowing down the MapWnd, that makes for our worst offender. But that's just a suspicion, I haven't chased it enough to really be sure about that.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 5:01 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3259
Dilvish wrote:
I think the biggest issue has to do with cascading waves of ObjectChangedSignals in the MapWnd. Notice that the delay when you change the Focus on just a single planet in the SidePanel is very similar to the entire delay for changing the Focus on a whole set of planets via right-click in the ObjectsList Window. I rather suspect it is similar cascades of update signals, slowing down the MapWnd, that makes for our worst offender. But that's just a suspicion, I haven't chased it enough to really be sure about that.
It is massively quicker to change the focus of 10+ systems via objects menu than it is to change one via sidepanel as long as none of the systems you're changing are displayed in the sidepanel. Other planets displayed is fine, as long as none of them are mass changed.

This makes zero sense to me but it's the way it is.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 5:09 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12013
Location: Munich
Dilvish wrote:
I think the biggest issue has to do with cascading waves of ObjectChangedSignals in the MapWnd.
That may be a big issue, but it doesn't have much to do with turn processing times.


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 5:11 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
Dilvish wrote:
I think the biggest issue has to do with cascading waves of ObjectChangedSignals in the MapWnd.
Regarding the increasing sluggishness of the UI in the later stages of the game, you're right of course. But we've been talking about the increasing turn processing time, haven't we?

Although the UI sluggishness is most certainly the bigger issue, no question.

EDIT: Oh, Geoff beat me to it.


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 5:22 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4374
Geoff the Medio wrote:
That may be a big issue, but it doesn't have much to do with turn processing times.
If whatever it is you're referring to by 'turn processing time' excludes updating the MapWnd, then it seems to me to be a not so useful metric for user experience of lag.

I don't have time to chase down details right at the moment, but later today hopefully I can come up with some time to make some more specific charts, two of them focused on the amount of time the server takes for making its two updates each turn, and corresponding ones for the human client processing those updates. I suppose ideally I can show them all in a single chart together with total elapsed turn-to-turn time.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 6:54 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
Dilvish wrote:
If whatever it is you're referring to by 'turn processing time' excludes updating the MapWnd, then it seems to me to be a not so useful metric for user experience of lag.
Oh, you suspect the updating of the map window to be the main culprit for the long turn processing times? I've to admit, I never thought of that...


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 7:31 pm 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 224
To follow up on that: Having a system selected and thus the side panel opened increases the time between turns significantly for me. So that the UI has a significant influence seems plausible to me.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 8:06 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3259
Morlic wrote:
To follow up on that: Having a system selected and thus the side panel opened increases the time between turns significantly for me. So that the UI has a significant influence seems plausible to me.

It had never occured to me to test this, but agreed, getting from turn 195 to 196 with no fleet or sidepanel open was noticeably faster for me than getting from turn 196 to 197 with both a fleetwnd and the sidepanel open, and the sidepanel noticeably, um, shuddered(? not sure of best term) at each update, and not just because it was a shared system and one of my troop ships turned up.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 8:14 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12013
Location: Munich
Probably a call to disable object signals could be inserted before turn-update-meter-calculations on the client, which might eliminate some of this effect...


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 9:38 pm 
Offline
Space Krill

Joined: Tue Aug 04, 2015 12:11 pm
Posts: 6
Vezzra wrote:
Dilvish wrote:
I think the biggest issue has to do with cascading waves of ObjectChangedSignals in the MapWnd.
Regarding the increasing sluggishness of the UI in the later stages of the game, you're right of course. But we've been talking about the increasing turn processing time, haven't we?

Although the UI sluggishness is most certainly the bigger issue, no question.

EDIT: Oh, Geoff beat me to it.


From my simple man gaming experience - I was playing today and end up with two AIs (one being previously killed): turn change rate was very sluggish, reaching even 100+ seconds, BUT when I killed enemy fleet consisting of 150 ships, the game just "unblocked" - and turns changed reliably much, much faster to a normal level - up to 5 seconds, even less. This enemy fleet was very stationary - it just stood mostly on one system (I'm lame, so was playing against turtles). The other AI had around 120 ships, and I was close to 100.

So I guess in my case, a lot of processing is strongly connected with overall number of ships, and not so much with other aspects.

I will make another game maybe tommorow and will gather data according to given instructions.


Top
 Profile  
 
PostPosted: Wed Aug 05, 2015 9:59 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12013
Location: Munich
See if something like this affects the sidepanel-open turn delay effect:
Code:
diff --git "a/C:\\Users\\Geoff\\AppData\\Local\\Temp\\TortoiseGit\\Map7FFC.tmp\\MapWnd-270f542-left.cpp" "b/C:\\Users\\Geoff\\Desktop\\FreeOrion_VS2013_SDK\\FreeOrion\\UI\\MapWnd.cpp"
index bcda01d..43efc84 100644
--- "a/C:\\Users\\Geoff\\AppData\\Local\\Temp\\TortoiseGit\\Map7FFC.tmp\\MapWnd-270f542-left.cpp"
+++ "b/C:\\Users\\Geoff\\Desktop\\FreeOrion_VS2013_SDK\\FreeOrion\\UI\\MapWnd.cpp"
@@ -2285,6 +2285,8 @@ void MapWnd::InitTurn() {
     // FIXME: this is actually only needed when there was no mid-turn update
     universe.InitializeSystemGraph(HumanClientApp::GetApp()->EmpireID());
 
+    universe.InhibitUniverseObjectSignals(true);
+
     // update effect accounting and meter estimates
     universe.InitMeterEstimatesAndDiscrepancies();
 
@@ -2299,6 +2301,8 @@ void MapWnd::InitTurn() {
 
     GetUniverse().ApplyAppearanceEffects();
 
+    universe.InhibitUniverseObjectSignals(false);
+
     // set up system icons, starlanes, galaxy gas rendering
     InitTurnRendering();
 


Top
 Profile  
 
PostPosted: Sat Jan 30, 2016 12:28 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12013
Location: Munich
Geoff the Medio wrote:
See if something like this affects the sidepanel-open turn delay effect:
Code:
diff --git "a/C:\\Users\\Geoff\\AppData\\Local\\Temp\\TortoiseGit\\Map7FFC.tmp\\MapWnd-270f542-left.cpp" "b/C:\\Users\\Geoff\\Desktop\\FreeOrion_VS2013_SDK\\FreeOrion\\UI\\MapWnd.cpp"
index bcda01d..43efc84 100644
--- "a/C:\\Users\\Geoff\\AppData\\Local\\Temp\\TortoiseGit\\Map7FFC.tmp\\MapWnd-270f542-left.cpp"
+++ "b/C:\\Users\\Geoff\\Desktop\\FreeOrion_VS2013_SDK\\FreeOrion\\UI\\MapWnd.cpp"
@@ -2285,6 +2285,8 @@ void MapWnd::InitTurn() {
     // FIXME: this is actually only needed when there was no mid-turn update
     universe.InitializeSystemGraph(HumanClientApp::GetApp()->EmpireID());
 
+    universe.InhibitUniverseObjectSignals(true);
+
     // update effect accounting and meter estimates
     universe.InitMeterEstimatesAndDiscrepancies();
 
@@ -2299,6 +2301,8 @@ void MapWnd::InitTurn() {
 
     GetUniverse().ApplyAppearanceEffects();
 
+    universe.InhibitUniverseObjectSignals(false);
+
     // set up system icons, starlanes, galaxy gas rendering
     InitTurnRendering();
 

Bump...


Top
 Profile  
 
PostPosted: Fri Apr 29, 2016 7:28 am 
Offline
Space Krill

Joined: Fri Apr 29, 2016 7:06 am
Posts: 3
I have been programming for about 30 years, named by UCLA as the best programmer on the planet. (Not like that matters much, and I only stated vague credentials for the purposes of my response). I have only developed a couple games, so please bare with me, and I am new at this game. I am running a 2.8ghz quad core with 8gb ram and after turn 400 (roughly), the turn rate tends to be 30-45 seconds with a single AI (I am just learning the game) and 200 star systems.

I have noticed that my CPU spikes but ram stays fairly constant. If I were to troubleshoot this scenario, I would say that what is currently in my viewfinder (screen, viewable part of the universe) should be the only portion of the program using much CPU and the non-viewable areas should be shelled out to ram. It may have a slight effect on movement around the map (which can be remedied, or improved) but would (I am quite sure) speed up the turn progress...?


Top
 Profile  
 
PostPosted: Tue May 17, 2016 2:11 pm 
Offline
Space Krill

Joined: Sat Oct 24, 2015 9:32 am
Posts: 1
Hello everyone.

I always encounter a very long turn duration when advancing in the game.
Around turn 200-300, turn change takes 4 to 5 minutes when autosave is off, and one hour (yes, 60 minutes !) on AUTOSAVE turns.

Moreover, manual save is never allowed, because AIs always stays "green >" up to human player's end of turn.

My configuration is :
* Windows 7 Home 64-bits.
* Intel Core i7 Q720 @ 1.6 GHz, 4 Gb RAM, Windows performance Index = 5.9
* nVidia GeForce GT 330M
* FreeOrion_2016-05-10.2a6b7b4_Test_Win32

Having played Turtle or Aggressive AIs.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 46 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group