Howto:Optimizing FlightGear for mobile devices: Difference between revisions

Jump to navigation Jump to search
Line 204: Line 204:
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. 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.
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.


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.
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.

Navigation menu