About freeorion's performance

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

Moderator: Committer

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

Re: About freeorion's performance

#31 Post by Dilvish »

pheldens wrote:

Code: Select all

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                      
13694 user      20   0 1105m 146m  39m R  103  1.8 159:44.00 freeorion
Ok, but what are the details on the game-- galaxy size, and turn, number of AIs, for example. Can't really assess anything without some info like that.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: About freeorion's performance

#32 Post by pheldens »

this was while displaying the techtree, when viewing the starmap it drops back to 50% cpu load

6 AI 150 systems, more or less default

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

Re: About freeorion's performance

#33 Post by Dilvish »

pheldens wrote:this was while displaying the techtree, when viewing the starmap it drops back to 50% cpu load
6 AI 150 systems, more or less default
Hmm, for me it doesn't seem to make any difference whether I'm showing the tech tree or not (whether it's zoomed in or not, showing all the techs). How far along in the game is that? With default settings the monsters can sometimes proliferate out of hand and really drag down performance.

Also, you compiled yourself, right? Could you double check the cmake settings to see if it compiled it as 'Release' or as 'Debug'? The default used to be 'Debug' which could noticeably slow things down; its not that long ago that we changed the default to 'Release'.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: About freeorion's performance

#34 Post by pheldens »

cpu not maximal, gpu not maximal, yet still low fps, whats causing this?


export GALLIUM_HUD=GPU-load,cpu0+cpu1+cpu2+cpu3
./freeorion
Attachments
see fps through transparency
see fps through transparency
research.png (183.34 KiB) Viewed 1583 times

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

Re: About freeorion's performance

#35 Post by pheldens »

for starmap

(btw this image uploader crashes the session/forum often)
Attachments
starmapx.png
starmapx.png (169.35 KiB) Viewed 1573 times

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

Re: About freeorion's performance

#36 Post by pheldens »

The compile isn't a debug build as far as I can tell, it makes stripped optimized binaries -O3/-O2 -s when observing the cmake buildprocess when its building.

The AI threads do DEBUG loglevel logging when it's running, leading to quite large logfiles, seen them at 40MB a piece (however this has little impact on performance)

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

Re: About freeorion's performance

#37 Post by raptor »

I had already narrowed down some of the poor performance of the tech-tree to (I think) the font rendering. I posted about it here:

viewtopic.php?f=9&t=9410

(The idea for a fix was dismissed at the time because it was misread.) The basic idea is to implement a font-glyph cache to improve rendering performance. GG may or may not already have such a cache; if so, it may be poorly implemented.

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

Re: About freeorion's performance

#38 Post by adrian_broher »

raptor wrote:The idea for a fix was dismissed at the time because it was misread.
There was nothing misread. The issues mentioned in the thread still exist.
raptor wrote:The basic idea is to implement a font-glyph cache to improve rendering performance. GG may or may not already have such a cache; if so, it may be poorly implemented.
Such mechanism already exists. The only reason why this wasn't addressed is because nobody cares enough to identify the exact problem and fix it. Just throwing a library at a problem doesn't make bugs magically disappear.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: About freeorion's performance

#39 Post by raptor »

None of the issues you brought up in that thread about the library exist (I know this because I have implemented it), which is why I thought you misread it. I'm sorry if I'm mistaken.

But with that said, you are right in that just throwing a library at something doesn't always fix it. If GG does indeed have a glyph-cache, then I wonder if it is actually helping...

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

Re: About freeorion's performance

#40 Post by adrian_broher »

raptor wrote:None of the issues you brought up in that thread about the library exist (I know this because I have implemented it), which is why I thought you misread it. I'm sorry if I'm mistaken.
I can give you the reasons for the issues:
  • I'm not willing to maintain a CMake build system for a external dependency, may it be in or out of the FO source. If you like to do so for your project: great for your project.
  • OpenGL texture states are not restored at all by the library. It assigns textures, but doesn't restore the old texture, it disables the texture unconditionally. Given the already existing FO rendering code this screams for subtle bugs because of the stateful OpenGL nature.
  • NIH means 'not invented here'. With 'fine libraries around' I mean FreeType, which is pretty much the de-facto standard for loading TrueType, rendering and measuring fonts. When I read the header 'stb_truetype.h' I see things like: TODO: crashproof on bad data or TODO: hinting? (no longer patented), things that FreeType already has implemented.
Also the library does essentially the same as the GG implementation does.
raptor wrote:But with that said, you are right in that just throwing a library at something doesn't always fix it. If GG does indeed have a glyph-cache, then I wonder if it is actually helping...
Here is my guess: The glyph cache (quad coordinates and texture coordinates) is rebuild every frame, regardless if the underlying text has changed. This would make every caching mechanism useless.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: About freeorion's performance

#41 Post by raptor »

Thank you for clarifying. I understand your points much better now.

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

Re: About freeorion's performance

#42 Post by raptor »

I did a callgrind analysis of the tech-tree window. I started the game, went into the tech-tree as fast as possible, showed all techs and made sure I was zoomed in enough that the tech names rendered (this reduced FPS to about 1/2 on my system). I then let it sit for about 5 min in that window.

Sure enough, the largest culprits are (with absolute percentages of the whole program):
1. GG::Font::RenderCachedText() (~19%) with most of the processing being GL calls.
2. TechTreeWnd::LayoutPanel::Render() (~12%) with 8% in PartlyRoundedRect() and 3% in GG::StaticGraphic::Render()

See graphics below. Also, here is the callgrind file (sorry for using an upload provider, it was a bit too large):
http://s000.tinyupload.com/index.php?fi ... 8886060686
Attachments
TechTreeWnd.png
TechTreeWnd.png (128.03 KiB) Viewed 1506 times
RenderCachedText.png
RenderCachedText.png (60.68 KiB) Viewed 1506 times

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

Re: About freeorion's performance

#43 Post by adrian_broher »

Thanks for taking the time to investigating the cause. I have some question on the output.

What do I see for example in the left branch below the GG::Font::RenderCachedText named 0x0…0752c780? Is that a function without a debug symbol? It's causing the majority of the performance hit within the GG::Font::RenderCachedText function.

I assume the percentage showed everywhere is the total CPU time used by the client application (meaning 13.5% it's hanging around in 0x0…0752c780) and not the CPU time relative to the caller?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

#44 Post by Geoff the Medio »

GG::Font::RenderCachedText is doing a series of OpenGL calls. For a large number of separate bits of text, such as the tech screen or (I suspect) the map screen, this will involve many repeated bindings of the font texture... perhaps more so for the tech screen, as the ShadowedTextControl that are used in TechPanel contains two GG::TextControl as members, which are collectively rendered 5 times each (with each time re-binding the texture) per ShadowedTextControl render call. This could probably be re-implemented by inheriting from GG::TextControl and override the Render function to work more efficiently. Alternatively, GG::Font could be given a RenderShadowedCachedText function to do the shadowing effect more efficiently, although that's a bit of an odd special case...

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

Re: About freeorion's performance

#45 Post by raptor »

Yes, the percentages are as a percentage of the whole instead of relative to parent.

Those missing symbols are the OpenGL function calls to the NVIDIA drivers I'm running (Linux, openSUSE 13.2 x86_64). I'm not sure if I can get the exact symbol names.

I suspect that there is something sub-optimal about the font caching - maybe because of the constant re-binding? Could a texture cache be bound only once at application start-up, then just modify the quad coordinates of the glyph when rendering? I'm afraid I don't understand much of GG's internals yet...

Post Reply