To look at the underlying C++ code, you only need to understand how constructors and destructors work: a class constructor is invoked whenever a new object is created, it's typically a method having the same name as the class itself without any return type associated - e.g:
- Code: Select all
class Foo {
Foo() {} // embedded/inline constructor
};
// or separate constructor
Foo::Foo() {}
Equally, the destructor is invoked whenever objects get destroyed (freed), the name is simply the class name prefixed with a tilde character:
- Code: Select all
class Foo {
~Foo() {} // embedded/inline constructor
};
// or separate constructor
Foo::~Foo() {}
The standard mechanism for making FlightGear "log" stuff to the console (or log file) is using the SG_LOG() macro, commonly using this:
- Code: Select all
SG_LOG(SG_GENERAL, SG_ALERT, "my MESSAGE");
In conjunction, these 3 pieces of info give us everything to track allocation/de-allocation of RoutePath related classes, i.e. by either adding or modifying the corresponding constructors/destructors to make them echo stuff to the console using the SG_LOG() macro.
So it appears that the growth per hour increases with the number of waypoints. The longer the flight, the more likely it is to have more waypoints.
yeah, that would make sense - my ballpark calculations were also using the assumption that a number of structs/classes kept being allocated (and referenced) without ever being freed - so the the longer the route (as in waypoints), the more leaking going on - even though, the distance of the route doesn't matter as much, it's more about number of waypoints and time spent running apparently.
People do keep updated with Git and check release candidates. I update every few days, but this has escaped me because I've not been doing long route manager flights since Christmas. Was there an announcement anywhere that indicated there were major changes to the route manager in the 3.4 RC? I think it would be helpful if users who do test could be pointed to tender areas when the RC comes out, or on an ongoing basis for people who run the Git version.
I guess that would be best discussed on the devel list - ideally, people doing such flights regularly would provide a corresponding "fgtape" file using a standard aircraft and get this committed to $FG_ROOT into some kind of "Tests" directory containing pre-recorded flights for doing regression testing in an automated fashion. The thing to keep in mind here is that those among us able (and willing) to troubleshoot such issues are most unlikely to ever actually use FlightGear like this, which certainly includes Zakalawe. Thorsten recently also mentioned that he'll typically just start up FlightGear a few dozen of times using a simple aircraft to test things, without really doing any "real" flying at all. So there are certainly a number of use-cases that aren't getting much attention unfortunately.
Which is why it would be a good idea for people to provide flight recorder tapes covering use-cases they care about, and get those committed to fgroot (fgdata) - so that we can grow a library of useful flights to do regression testing - as long as those flights are using standard aircraft and features, they should also be useful for people entirely new to FlightGear.
While developers, and power users, could use those flights to run FG in an unattended fashion, without having to be overly familiar with aircraft internals (think aircraft startup procedures, IAPs, STARs and other VA stuff) - we could even use accelerated sim-time to complete whole flights in a fraction of the time normally required, while stress-testing a bunch of underlying systems, including the route manager, autopilot, and FDM. Many of those don't necessarily require any "rendering" - which is touching on the whole "headless" effort that James has been working towards independently:
http://wiki.flightgear.org/FlightGear_HeadlessSo as you can probably tell, there's certainly some momentum here, it just takes people to get this started - i.e. by providing said flight recorder tapes and getting them committed to the base package, while offering to maintain/update them in the time to come - ideally, also showing a willingness to do regression testing in the form you've shown here.
At some point, this could then even be done in an automated fashion on the build server directly - but we
will need people to provide fgtape files covering different use-cases to exercise different code paths, without core developers necessarily having to spend hours doing transcontinental flights in a twin-engine turbprop, you know
But I guess that is something that should be better discussed on the devel list, once we have people offering to provide a few pre-recoreded fgtape files to get this started ...
I looked at the thread again, and I do remember it - it wasn't obvious to me that the OP also stated somewhere that he was using the route manager, but like I said I was skeptical about some conclusions drawn there. And regarding Thorsten's conclusions specifically: he's a rendering guy, and primarily interested in visual stuff, especially scenery/terrain - so with his background, it is normal that everything looks like a terrain/scenery related issue to him - i.e.
law of the instrument: if your only tool is a hammer, everything looks like a nail
Frankly, Thorsten is usually right - and unfortunately he's pretty aware of this circumstance
, so he can be rather compelling even when he's very wrong, and most people don't bother responding to him then, because it is taking too much time and energy to argue with someone so elaborately...
We've had the same discussions about
subsystem-level memory tracking in the
TerraGear LOD thread, where Thorsten also strongly disagreed with the notion that this would have helped identify certain issues much earlier (including this one by the way).
In retrospective, it is unfortunately true that most of us (including myself ...) have repeatedly suggested workarounds to lower overall resource utlization instead of looking at identifying the underlying culprit for resource leakage elsewhere - which also includes the whole "reverting back to WS 1.0" advice, but also the leaking listeners issue Torsten and Rebecca fixed a whole ago. So there isn't just uninformed end-users, there are also uniformed contributors coming up with pathetic excuses for FlightGear's lack of explicit resource management...
The PagedLOD stuff is obviously great, but it only affects renderings - more specifically, only scenery/terrain, anything outside these domains isn't affected, which includes 99% of all other SGSubsystems in FlightGear, most of which aren't even yet making use of smart pointers ... (as can be see by this issue now).
So, basically, given FlightGear's growing complexity, what is needed is a dedicated means for OPTIONALLY tracking resource utilization based on subsystems/features, i.e. in terms of RAM/CPU and GPU/VRAM utilization, which -in conjunction with a community-grown library of use-cases (think flight recorder tapes)- could then be used to run FlightGear regression tests in a semi-automated and unattended fashion to gather statistics that don't leave much room for speculation.
So I guess it would be best to look forward and just try to find a way to prevent such misunderstandings in the future, and allow other contributors to draw conclusions without having to be intimately familiar with the C++ code of each component in FlightGear, i.e. by coming up with benchmarks and test-cases that people care about and get those committed to fgdata, so that developers can use those for benchmarking FG performance - even completely unrelated to scenery/terrain or visuals in particular.