Howto:Optimizing FlightGear for mobile devices: Difference between revisions

Jump to navigation Jump to search
Line 204: Line 204:
The performance monitor dialog reads all data from the property tree and it is created dynamically using a Nasal module in [http://gitorious.org/fg/fgdata/blobs/master/Nasal/performance_monitor/monitor.nas $FG_ROOT/Nasal/performance_monitor/monitor.nas]
The performance monitor dialog reads all data from the property tree and it is created dynamically using a Nasal module in [http://gitorious.org/fg/fgdata/blobs/master/Nasal/performance_monitor/monitor.nas $FG_ROOT/Nasal/performance_monitor/monitor.nas]


It would probably suffice to use "placement new" (i.e. pool memory) here, and overload the new operator at the SGSubsystem level (i.e. in SimGear), so that all subsystems use the overloaded new operator automatically. This would allow us to keep track of the number of memory allocations per subsystem, and also the amount of total RAM allocated by single subsystems. In addition, we could also track freeing via delete, too. And publish all the info to the property tree.
It would probably suffice to use "placement new" (i.e. pool memory) here, and overload the new operator at the SGSubsystem level (i.e. in SimGear), so that all subsystems use the overloaded new operator automatically and write allocation reports to the performance monitor.  
 
This would allow us to keep track of the number of memory allocations per subsystem, and also the amount of total RAM allocated by single subsystems. In addition, we could also track freeing via delete, too. And publish all the info to the property tree.


We could even provide a facility to register our own new/malloc operator for SimGear code, so that also non-FG/SG (subsystem) code, such as the Nasal GC, could be tracked memory-wise.
We could even provide a facility to register our own new/malloc operator for SimGear code, so that also non-FG/SG (subsystem) code, such as the Nasal GC, could be tracked memory-wise.

Navigation menu