Speeeed!

Talk about anything and everything related or unrelated to the FreeOrion project, especially Strategy Games.

Moderator: Oberlus

Message
Author
User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Speeeed!

#1 Post by Nagilum »

When the Game starts everything is pretty snappy but once you get into the 100 turn range and beyond the game consists mostly of waiting and I have no idea what it's doing.
You wait a minute to switch from one system to another, heck you even wait a minute when you accidentally select the system you already have selected!
You wait a minute when you select a ship so invading becomes a major undertaking.
You wait when you switch to production or research (even if there is nothing more to research!), you wait when you want to switch to "Design".
Simply re-opening the "Sitrep" takes ages and the worst part of it all: I have no idea what could possibly take that long!
All the game has to do is some AI & beancounting during the turns. After that everything that is displayed is the result of simple multiplication and or addition. Nothing that would take more than a microsecond on todays CPUs. The graphics is pretty simple as well, the only 3D stuff is the starmap but zooming in and out works very fast. The rest is just 2D stuff so it should be lightning fast and I really don't understand what's making the game so glacially slow.
Attached a recent save game for profiling..
Attachments
sav.sav.7z
(520.75 KiB) Downloaded 275 times

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: Speeeed!

#2 Post by eleazar »

While turns definitely are longer as the game progresses, because bigger-- more powerful AI empires have a lot more options to consider-- the lag you describe is not what most people seem to experience.

Exactly what version are you playing?
What are your basic hardware and OS stats?

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#3 Post by Nagilum »

Did you try the savegame?
Linux 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:48:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
It's a Probook 6460b.
[ 37.556] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+)
[ 37.556] (--) intel(0): Chipset: "Sandybridge Mobile (GT2+)"

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#4 Post by Nagilum »

I don't think the AI comes into play when I switch to a different view or review the "Sitrep".

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Speeeed!

#5 Post by Dilvish »

Nagilum wrote:I don't think the AI comes into play when I switch to a different view or review the "Sitrep".
Correct, they don't. In the late stage game the y can indeed start taking a lot of time for each turn, and I am continuing to work on streamlining that whilst keeping the AI competitive, but that all takes during an initial portion of each new turn.

The delays you're seeing are, I believe, pretty much all due to various updating processes that are intended to ensure that the UI is presenting current info reflective of any recent changes made though the UI, These processes often review a large number of effects relative to a large number of objects & so can take a long time. Also, with the portions that I have looked into, it kind of seemed to me that update-cascades are rather easy to touch off, can be repeated a surprising number of times from a single UI event, etc. I believe there has been a strong preference for over-updating rather then risking under-updating. Which does seem to me like the right way to start off, but it also seems good & ready for cleaning up now too.

Geoff has started streamlining at least some aspects of this, and already improved things notably, but I think there's quite a lot more that can be accomplished. I'm not sure if Geoff actually has available any kind of diagram of UI interactions and subsequent signal/update chains, but if not, it would probably be helpful if someone could do so.

Geoff, what do you say, care to specify some kind of development plan under which others of us can help you tackle this?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Speeeed!

#6 Post by Vezzra »

eleazar wrote:the lag you describe is not what most people seem to experience.
I just tried the savegame Nagilum provided and have to agree, at least to some degree. While (at least on my machine, a Core i7 2GHz MBP) the game is still playable, the delays when clicking on systems or selecting ships in fleets is noticeably slower than at the start of a game. On dated hardware this game would be completely unplayable at this stage. I've a similar game running on an old PC at turn 148, and it's barely playable anymore.

So this is definitely an issue that needs to be addressed long term. Especially if you are playing with larger maps and more opponents, even on current hardware you get noticeable lags at later stages of the game.

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#7 Post by Nagilum »

Just tested the Windows version and it is indeed a lot snappier.
Looks like this is a Linux specific performance issue. :-/

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

Re: Speeeed!

#8 Post by Geoff the Medio »

I think a lot of the slowness is due to memory allocations when doing all the calculations for things like figuring out what colony ship to default select for automatic colonization of planets in cases when there is not any selected colony ship and the game needs to pick one in order to put an estimated colony population on the autocolonize button. This gets re-done repeatedly during player turns in order to keep the UI updated for which system is being shown and what ships are or aren't selected. Other similar updates happen for other UI changes to ensure things are updated.

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#9 Post by Nagilum »

Pardon my ignorance but why not keep the game state in an embedded database (like SQLite), getting the next colony ship for colonization would be a simple select...

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Speeeed!

#10 Post by Dilvish »

Geoff the Medio wrote:I think a lot of the slowness is due to memory allocations when doing all the calculations for things like figuring out what colony ship to default select for automatic colonization of planets in cases when there is not any selected colony ship and the game needs to pick one in order to put an estimated colony population on the autocolonize button. This gets re-done repeatedly during player turns in order to keep the UI updated for which system is being shown and what ships are or aren't selected. Other similar updates happen for other UI changes to ensure things are updated.
For Linux Systems, and at least for your example of auto-colonize, I have to disagree. I've noticed very little difference before and after auto colonize. The 'safe move' feature is kind of related to the things you cite, in that in its initial implementation the systems filter used for safe pathing gets recalculated on the fly each and every time the cursor hovers over a new system, and I haven't noticed really any lag with that at all, even in late stage games, whereas in a late stage game I can notice significant lag from selecting new fleets, ships, or systems. I think it's because actually selecting something new generally triggers a cascade of update signals, it seems to me.

Given that UI lag does get to be so noticeable, but the causes are less clear, I suppose we should get some detailed timing reporting built into UI responses so we can really know what we're talking about.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Speeeed!

#11 Post by Geoff the Medio »

Dilvish wrote:
Geoff the Medio wrote:...things like figuring out what colony ship to default select for automatic colonization of planets... Other similar updates happen for other UI changes to ensure things are updated.
For Linux Systems, and at least for your example of auto-colonize, I have to disagree. I've noticed very little difference before and after auto colonize.
Auto-colonize might not be particularly bad, but other similar updates do happen when selecting or changing settings of things.

It may also not be anything to do with signals and updates, if it's a memory allocation slowness issue. The original post has issues with opening the sitrep window. The only reason I can think that would be particularly slow is memory allocations for all the sitrep row controls, which get recreated every time the sitrep panel is opened, similar to what was happening with the ships rows being fully recreated every time something changed that affected any of the ships or fleets in it. If there are hundreds of sitreps being shown, that could be a lot of rows. A similar optimization could be (edit: has been) done for that as was done for the ship rows, but if the fleets window is still slow on Linux, then it might not make much difference.
...we should get some detailed timing reporting built into UI responses so we can really know what we're talking about.
There is a bunch of that already, but more can be added. The ScopedTimer class is useful.

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#12 Post by Nagilum »

Yeah, some exact measurements are in order, when I loaded the savegame today (under Linux) the Sitrep worked just fine though only three dozen messages.
Loading the savegame itself takes about two to three minutes. When I resign right away it takes about a second to the startscreen - if play a bit and then resign it can take like two minutes to resign.
I also noticed that the objects windows still shows a lot of enemy fleets which I don't see at the starfield. I have nothing left to research so I doubt they are cloaked.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Speeeed!

#13 Post by Dilvish »

Nagilum wrote:I also noticed that the objects windows still shows a lot of enemy fleets which I don't see at the starfield. I have nothing left to research so I doubt they are cloaked.
Ya, if they get destroyed out of your field of detection then I think they're stuck on the list. I don't think there's anything better to do than restrict your display of fleets to visible ones.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: Speeeed!

#14 Post by Geoff the Medio »

Dilvish wrote:
Nagilum wrote:I also noticed that the objects windows still shows a lot of enemy fleets which I don't see at the starfield.
Ya, if they get destroyed out of your field of detection then I think they're stuck on the list. I don't think there's anything better to do than restrict your display of fleets to visible ones.
If your empire doesn't know something's been destroyed, it considers it a previously visible object. As Dilvish noted, there are filters for the object view to control what is listed.

User avatar
Nagilum
Release Manager, Design
Posts: 212
Joined: Thu Dec 31, 2009 3:25 pm
Location: Germany

Re: Speeeed!

#15 Post by Nagilum »

Dilvish wrote:
Nagilum wrote:I also noticed that the objects windows still shows a lot of enemy fleets which I don't see at the starfield.
Ya, if they get destroyed out of your field of detection then I think they're stuck on the list. I don't think there's anything better to do than restrict your display of fleets to visible ones.
I disagree, the obvious thing to do would be to remove destroyed objects. The reason I brought it up is that I'm wondering if that accumulation of ships contributes to the decrease in speed.
If that's not the case the discussion is mostly irrelevant.
I still don't understand how the game can keep the CPU busy for _several seconds_ when I just select a different ship. The numbers being displayed have either been calculated during the turn or are the result of a handful of simple equations..
Btw. what's up with those numbers, if I have three ships in a fleet the fleet will show "2.9" and similar for invading the game will show "7.9" when it should show "8" for example? Why use floating point for integer type data in the first place?
But that's a different issue.

Post Reply