User:Hooray/SandBox/FlightGear Performance and Run-Time Footprint Debate
|Work in progress|
This article or section will be worked on in the upcoming hours or days.
See for the latest developments.
|(Originally, there actually was a conceptual separation i.e. WRT to master/next branches, but this hasn't been used in years, despite having been established by Tim Moore as such.
But these days, we're simply lacking the manpower to do so.)
|The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees.
|I had banned myself from KSFO because I would get to swap even before seeing anything and now I tried and fgfs starts and is usable in my 32 bit debian system with 2GB of RAM. Simple planes and no multiplayer though, but is really great improvement.
CPU vs. GPU work
Our Main Loop & HLA
Lack of Feedback from End Users
|many people don't even know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data
Poor Quality of Bug Reports
FlightGear light ?
|Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders
Resource Utilization Tracking
|that's basically a matter of providing some kind of dedicated monitoring function, analogous to the existing system monitor, which also tracks other resources, such as RAM/VRAM - at least optionally.
|Thus, while the idea to scale features up/down, depending on available resources, the majority of the legacy code in FG (especially anything unrelated to OSG/rendering) would need to be explicitly re-architected to 1) track memory allocations & freeing, and to also adjust subsystems and their features accordingly.
|Also, eventually adopting would be a great way for some projects like local weather to parallelize more and more code.
Moving some Nasal code to other cores
|some people have repeatedly expressed an interest in eventually running a weather simulation asynchronously from the main loop, i.e. either multi-threaded or in a separate process (the HLA interface was mentioned by Mathias and Torsten).
|This isn't the first person/contributor to state pretty clearly that they're kinda disappointed with the way FG has evolved over the years, some others stated pretty clearly that even a recent version of X-Plane looks and works better than FG 3.x using the same hardware - so I guess we should take this for what it is, i.e. feedback demonstrating that people no longer know how to scale down FlightGear's features. Admittedly, I also find myself having to do quite a bit of tweaking these days, despite having fairly powerful hardware. Stating that all these are optional features and that people "merely" need to disable those, is as short-sighted as the whole multi-threading debate that we've been having since ~2006 ... Obviously, the "minimal startup profile" should still work for people, and it should easily provide ~60 fps, but that's not what people want FG to look like, and there are other products that simply provide a better experience.
|So, I'd say we do have a problem, but what people consider the problem is usually just a symptom and not the real culprit.
But that should be understandable, most non-coders cannot easily understand all the factors involved here.
|To see for yourself, start up in a place without any scenery, keep FG running for several hours and then see the valgrind report (one of those tools that you refuse to use), while it's true that valgrind outupt is misleading in the context of OSG's ref_ptr's (smart pointers, that manage memory), we do have a number of memory-leaking features, including particles and even effects.
|Things like a slow Nasal/GC scheme are those that you cannot easily track down, without using tools like a profiler, debugger or leaks checking tool.
|I never even questioned that our current issue is scenery related, I just said that we've been seeing other issues, and I pointed out that a few of us provided patches to recognize such issues much earlier (the v2.0 scenery issue was RANDOMLY identified by Atlas core developer Brian Schack if you remember). Had we integrated the corresponding resource tracking patches that we discussed (and posted) 4+ years ago, we would have had a much better chance of detecting such issues - even regardless of them being specific to scenery, the Nasal GC or whatever.
|All it takes to run the recent FG version on old hardware is to not use optional features and dial down the configuration. The project is most definitely not going into any direction making it impossible for some people to use FG - there's huge concern over backward compatibility on the devel list.
|I mean, in that context FG is just a platform which runs the data you throw at it. Someone decided to develop that 777-S at high detail, and then it consumes more memory. Should the devel team veto detailed aircraft based on the notion that they might not run on all systems? Or could we perhaps trust users to select aircraft based on what runs on their system and what they want to have?
|I agree wrt to valgrind, specifically if you want to profile, use callgrind and see in pretty colours how much time a piece of code takes to run. Requires lots of patience though.