Howto:Using the Performance monitor without PUI

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
Cleanup.png This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

Background

PUI being slow, using it for the performance monitor stats is affecting simulator performance unnecessarily.

Approach

The performance monitor does not need to be used using the monitor.nas script, it can also be enabled manually using a property switch (during startp, but also at runtime). The statistics will then be written to a dedicated branch in the property tree (location), so that they can be inspected using a number of ways:

  • the pronberty browser
  • telnet
  • httpd interface
  • Canvas
  • ...


Have you checked the performance monitor to see if there are any obvious candidates showing up there ? If in doubt, enable the performance monitor using the property browser - and then inspect it using the property browser and/or the httpd/telnet interfaces, i.e. so that you can disable/exclude PUI (our legacy GUI) entirely.

And can you reproduce this at all in a non-terrain location (above ocean/minimal startup profile) ? it would be better to look at the performance monitor stats without using the PUI dialog, e.g. by using the httpd-based property browser or the telnet daemon (--props).

You will have to manually activate the property browser (if in doubt, refer to menubar.xml for details):

Use "Debug -> Toggle Subsystem Statistics" to enable/disable. It prints min/max/average and std-deviation for each of FG's subsystems to the console. The statistics interval is configurable via /sim/timing-statistics/interval-s Since there are a lot of submodules in FG (most of them are very friendly and don't consume much time), you can restrict the output to modules exceeding a certain minimum execution time - or a certain jitter (hey!). Use /sim/timing-statistics/min-time-ms and /sim/timing-statistics/jitter-ms to configure the filters (in milliseconds, obviously). Should help finding performance and jitter issues if they were caused by one of our internal subsystems.[1]

Alternatively, use the property browser, which is more lightweight than the performance monitor dialog.

References

References