20,741
edits
Howto:Optimizing FlightGear for mobile devices: Difference between revisions
Jump to navigation
Jump to search
Howto:Optimizing FlightGear for mobile devices (view source)
Revision as of 09:39, 5 August 2012
, 5 August 2012→Optimizing at the Source Code Level
| Line 166: | Line 166: | ||
While disabling these systems can be fairly easily accomplished using ifdefs, care must be taken that FlightGear still builds properly and that no other systems are trying to access disabled subsystems, so this will involve repeated edit/build/debugging sessions using gdb. But that doesn't need to be done on the target device, it could just as well be completed on a conventional PC. | While disabling these systems can be fairly easily accomplished using ifdefs, care must be taken that FlightGear still builds properly and that no other systems are trying to access disabled subsystems, so this will involve repeated edit/build/debugging sessions using gdb. But that doesn't need to be done on the target device, it could just as well be completed on a conventional PC. | ||
== Tracking Memory Utilization at the Subsystem-level == | |||
It's getting obvious that it might be beneficial to extend the build-in performance monitor system such that it also supports tracking memory consumption per subsystem. | |||
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. | |||
We could even provide a facility to register our own new operator for SimGear code, so that also non-FG/SG (subsystem) code, such as the Nasal GC, could be tracked memory-wise. | |||
Once the performance monitor is extended like that, it should become obvious how much memory is used by each subsystem, so that it will be easier to do further optimizations, i.e. possibly using a lazy allocation scheme or by optimizing the underlying data structures. | |||
== Related == | == Related == | ||