20,741
edits
Resource Tracking for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Resource Tracking for FlightGear (view source)
Revision as of 20:38, 4 September 2014
, 4 September 2014no edit summary
m (→Background) |
mNo edit summary |
||
| Line 4: | Line 4: | ||
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]] | [[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]] | ||
{{FGCquote | {{FGCquote | ||
|3.2 switched the base-package scenery to the | |3.2 switched the base-package scenery to the high-resolution (i.e. memory-intensive) version, with the result that FG on default settings hangs my system (4GB memory, Intel graphics, no swap). | ||
high-resolution (i.e. memory-intensive) version, with the result that FG | |||
on default settings hangs my system (4GB memory, Intel graphics, no swap). | It becomes usable after reducing the bare LOD range, but one needs to know to do that; I'd like to replace the fixed defaults by something <br/> | ||
that automatically adjusts to the hardware, but haven't yet got around to this. | |||
It becomes usable after reducing the bare LOD range, but one needs to | |||
know to do that; I'd like to replace the fixed defaults by something <br/> | |||
that automatically adjusts to the hardware, but haven't yet got around | |||
to this. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32784078/ | |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32784078/ | ||
|title=<nowiki>Re: [Flightgear-devel] Download size, | |title=<nowiki>Re: [Flightgear-devel] Download size, | ||
| Line 20: | Line 16: | ||
}} | }} | ||
{{FGCquote | |||
|On File > Reset, memory usage drops from 1.3GB to 1.1GB then rises to 2.3GB (at KSFO not doing anything), suggesting that a large part of the <br/> | |||
old used memory isn't being freed, and often causing an out-of-memory hang/crash. Is this a known issue? | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32796961/ | |||
|title=<nowiki>[Flightgear-devel] Large memory leak on Reset</nowiki> | |||
|author=<nowiki>Rebecca Palmer</nowiki> | |||
|date=<nowiki>2014-09-04</nowiki> | |||
}} | |||
}} | |||
== Background == | == Background == | ||
{{Note|for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}}}} | {{Note|for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}}}} | ||