About freeorion's performance

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: About freeorion's performance

#61 Post by adrian_broher »

Base of branch (partial resolved research window):
best FPS): 15
worst FP: 1
max draw calls: 1.7k

Tip of branch (partial resolved research window):
best FPS: 30
worst FPS: 15
max draw calls: ~950

Data obtained with

Code: Select all

GALLIUM_HUD=fps,draw-calls ./freeorion
No visible artifacts. Go merge it.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: About freeorion's performance

#62 Post by MatGB »

MatGB wrote: Edit: on the main map window, it's not just a perception, massive improvement in mouse responsiveness and general control over screen and game.
To follow up on this and because I edited at the same time Geoff posted, before this patch my mouse, even on small maps, was very slow to catch up with me in game, now it's moving at the same rate as in, say, my browser window, as far as I can see. And I've just researched Omni Scanner, which normally causes a further slowdown, not with this.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: About freeorion's performance

#63 Post by Dilvish »

woot! Props to Geoff! (and raptor & adrian helping nudge things along). Sounds like this will be a nice improvement for many people.
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
Sloth
Content Scripter
Posts: 685
Joined: Sat Mar 17, 2007 12:28 am

Re: About freeorion's performance

#64 Post by Sloth »

Geoff the Medio wrote:
Sloth wrote:For me the easiest way to crash my framerate is to build the super testers takeover. With a big galaxy (250+) fully visible it even becomes hard to click on a system, because the mouse cursor reacts so badly.
Have you turned off background starfields and galaxy gas, and tried enabling or disabling optimizing system rendering?
The gas rendering was the culprit. The difference is huge! Everything else didn't matter.

Thanks for the hint Geoff!
All released under the GNU GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0 licences.

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

Re: About freeorion's performance

#65 Post by Geoff the Medio »

I always run "freeorion -r" as that turns off the (imo unnecessary) eye candy including galaxy gas, and a few other things...

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

Re: About freeorion's performance

#66 Post by MatGB »

Re the gas, I sorta like it, and my new machine can handle it, but it blurs very quickly with the molecular clouds, making them much harder to spot, could we have a bit of differentiation between them colour wise?
Mat Bowles

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

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#67 Post by pheldens »

thanks for the merge, my performance doubled from 10 fps to 20

User avatar
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: About freeorion's performance

#68 Post by vincele »

raptor wrote:I did a callgrind analysis of the tech-tree window.
Hello, can you share some of your experience doing so ?
Just a quick howto get on the tracks.
- how do you launch a callgrind analysis on FO
- is it solwing FO down badly ? By how much ?
etc...

Thanks
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

raptor
Space Squid
Posts: 87
Joined: Sat Jun 02, 2012 11:29 pm

Re: About freeorion's performance

#69 Post by raptor »

Hi,

I do this on Linux; my process is as follows:

1. Compile freeorion with debugging symbols. This means running a fresh CMake build. I do the following:

Code: Select all

cd /dir/to/freeorion/
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ln -s ../default
That last command just makes the resources available to the binary you just compiled in the 'build' directory. It takes about 1/2 hour for me to compile from scratch.

2. Use callgrind to launch freeorion. I run it with the newly created debug-symbol-enriched binary like so:

Code: Select all

valgrind --tool=callgrind ./freeorion
3. Be patient. Very patient. Callgrind will slow down the game by as much as 1/100 the normal speed. I had to wait about 5 min. for it to start up.
4. Start a very lightweight game (or as lightweight as possible). I chose 1 AI, 10 stars
5. Do your test plan. For the performance issues, my test plan was just to open the tech-window, show all locked techs, and let it render for 5 min.
6. Quit freeorion
7. Open the callgrind.out.1234 (or whatever the numbers are) file in a viewer. I use kcachegrind.
8. Analyze the callgraph. I'm no expert at this and sometimes you have to take care to find the correct node where the processing is being spent, and not a parent node.

User avatar
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: About freeorion's performance

#70 Post by vincele »

OK thanks, that's also how I do it, but to skip a lot of the overhead before the really interesting part, I do start it with:

Code: Select all

valgrind --tool=callgrind --instr-atstart=no ./freeorion
Then when I'm ready to gather the call traces, I do:

Code: Select all

callgrind_control -i on
After capturing my profile data:

Code: Select all

callgrind_control -i off
To avoid loosing to much time, I use a special build (-O2) but with the debug symbols still present...
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#71 Post by pheldens »

another profiler is sysprof
Image

User avatar
Ouaz
Dyson Forest
Posts: 232
Joined: Wed Aug 13, 2014 7:21 pm
Location: France

Re: About freeorion's performance

#72 Post by Ouaz »

I just tested the new build... and wow, the improvement is very noticeable.

- Before, when I selected a system right after the game loading, there was a freeze of 2-3 seconds before the sidepanel shows up. Now, it's instantaneous
- When I toggled all techs in the Research panel, it took 3-4 seconds. Now, it's instantaneous.
- Same with the unavaialable ship parts in the Production panel.

I don't know if it's related to this improvement, but I set the FPS limiter to 30 fps, but in the previous versions, it didn't seem to have any effect (it could go up to 50 fps despite the setting). Now, it seems to be a constant 30 fps (closing all windows and doing nothing, it goes up to 40 fps, then goes down to 30 fps). Nice.
I release every updated file under the CC-BY-SA 3.0 license.

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

Re: About freeorion's performance

#73 Post by MatGB »

MatGB wrote:
MatGB wrote: Edit: on the main map window, it's not just a perception, massive improvement in mouse responsiveness and general control over screen and game.
To follow up on this and because I edited at the same time Geoff posted, before this patch my mouse, even on small maps, was very slow to catch up with me in game, now it's moving at the same rate as in, say, my browser window, as far as I can see. And I've just researched Omni Scanner, which normally causes a further slowdown, not with this.
More feedback, I'm using the Windows laptop now and the improvement is even more noticeable than it was on Linux, vastly improved framerates, the game mouse pointer stays with the system pointer with no noticeable lag.

This is definitely worth highlighting in the changelog as while it didn't bother everyone for those of us it did it's a significant improvement in performance.
Mat Bowles

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

pheldens
Pupating Mass
Posts: 96
Joined: Fri Mar 15, 2013 12:54 pm

Re: About freeorion's performance

#74 Post by pheldens »

I have a feeling theres way more performance improvement possible, please keep at it to the point it runs @60fps on fast computers

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

Re: About freeorion's performance

#75 Post by Geoff the Medio »

pheldens wrote:I have a feeling theres way more performance improvement possible, please keep at it to the point it runs @60fps on fast computers
Yes, much of the GUI rendering, including almost any widgets that have details like curved edges, are rendered with very inefficient immediate OpenGL calls. Switching everything over to vertex buffers would help quite a bit, particularly on things like the research screen.

Post Reply