219
edits
Howto:Use the system monitor: Difference between revisions
Disabled some "Caution" text that i think was distracting from the main content.
m (category Performance_tuning) |
(Disabled some "Caution" text that i think was distracting from the main content.) |
||
| (23 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{Portability Navbar}} | |||
<!-- | |||
== Terms == | |||
{{FGCquote | |||
|1= those systems are not "processes", but just "loops" - i.e. whatever the thing is called in the list, you should append "update-loop" to it - and some names are still misleading (events=Nasal). | |||
|2= {{cite web | |||
| url = {{forum url|p=264426}} | |||
| title = <nowiki>Re: Su-15</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Nov 13th, 2015 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= FG is basically using cooperative multi-tasking-imagine it like a team of people (15+), all of whom need to finish their work and hand it over to the next person, so that a single frame can be produced - with some people (subsystems) being allowed to redo/check their work several times in a row (fdm, autopilot), while others will only get a single opportunity to update their internal state. | |||
Finally, it is this "team of people" that will produce a single frame - so whenever "someone" is too slow, it will end up causing stuttering. No matter the reason, scenery/terrain, Nasal etc - at some point, another subsystem will have to wait, which means fewer frames created per second. | |||
|2= {{cite web | |||
| url = {{forum url|p=264313}} | |||
| title = <nowiki>Re: Su-15</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Nov 13th, 2015 | |||
}} | |||
}} | |||
--> | |||
== The system monitor == | == The system monitor == | ||
[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]] | [[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]] | ||
<!-- | |||
{{Caution| | |||
{{FGCquote | |||
|1= the built-in performance monitor, and especially the GUI (it being used in PUI/PLIB)- is adding to the performance overhead you're seeing | |||
|2= {{cite web | |||
| url = {{forum url|p=243288}} | |||
| title = <nowiki>Re: FlightGear permanently damages the performance of comput</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = May 18th, 2015 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= you will want to use the http/telnet interfaces to watch the performance stats, because the GUI dialog using PUI/Nasal is dead-slow, and even adding to the overhead you are seeing | |||
|2= {{cite web | |||
| url = {{forum url|p=264313}} | |||
| title = <nowiki>Re: Su-15</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Nov 13th, 2015 | |||
}} | |||
{{FGCquote | |||
|1= "events" is the subsystem that triggers/runs Nasal timers, and any Nasal code (anywhere), may trigger the GC (garbage collector) - to see if that's the case, you can use the "GC tracker" patch in the sigar code we have. | |||
|2= {{cite web | |||
| url = {{forum url|p=258607}} | |||
| title = <nowiki>Re: How to tell if you are CPU or GPU limited (split)</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Sep 23rd, 2015 | |||
}} | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= You can get pretty accurate stats using the performance monitor - it will write everything to the property tree. To see for yourself, open the performance monitor dialog and then use the property browser to watch the performance monitor branch in the property tree, you can learn more by inspecting $FG_ROOT/Nasal/performance_monitor/monitor.nas | |||
As you can see there, the switch for enabling the monitor is /sim/performance-monitor/enabled (bool) | |||
This will work regardless of the PUI dialog, and you can view/access all stats (for each subsystem!) without showing the PUI dialog (=better performance) | |||
For a list of subsystems, go to /sim/performance-monitor/subsystems | |||
Note that you can also use the http (browser) or telnet protocols to do this while extending the logging protocol | |||
|2= {{cite web | |||
| url = {{forum url|p=258579}} | |||
| title = <nowiki>Re: How to tell if you are CPU or GPU limited (split)</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Sep 23rd, 2015 | |||
}} | |||
}} | |||
}} | |||
--> | |||
In FlightGear >= 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters. | In FlightGear >= 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters. | ||
| Line 17: | Line 91: | ||
So, frame spacing is a much better property to judge visual quality than just watching fps. | So, frame spacing is a much better property to judge visual quality than just watching fps. | ||
* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these). | * Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these). | ||
| Line 30: | Line 100: | ||
* A bit background on the FG subsystems may be necessary though to really judge what's going on: | * A bit background on the FG subsystems may be necessary though to really judge what's going on: | ||
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]). | ** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]). | ||
** the props (property tree) system make invoke Nasal callbacks via listeners | |||
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks). | ** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks). | ||
** The GUI system is another subsystem which may trigger Nasal hooks | ** The GUI system is another subsystem which may trigger Nasal hooks | ||
| Line 39: | Line 110: | ||
Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve... | Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve... | ||
== Discussed Enhancements == | |||
* decouple Nasal events from the "events" subsystem and use a new "events-nasal" instead {{forum link|p=164715}} | |||
* show average frame-spacing effect per subsystem as a percentage | |||
* show memory consumption per subsystem (overload the new operator) | |||
* plot graphs for the various metrics using the new [[Canvas]] system | |||
* track Nasal GC pressure (invocations) and total memory allocated [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg31762.html] | |||
= Debugging stuttering = | = Debugging stuttering = | ||
| Line 57: | Line 135: | ||
In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff. | In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff. | ||
== Profiling == | |||
For developers, and people building from source, FlightGear versions >= 2.9 provide real profiling support using Google PerfTools, for details please see [[Built-in Profiler]]. | |||
= Interpreting the OSG on screen stats = | = Interpreting the OSG on screen stats = | ||
{{Main article|OSG on screen stats}} | |||
[[Category:Howto]] | [[Category:Howto]] | ||
[[Category: | [[Category:Scenery enhancement]] | ||