Board index FlightGear The FlightGear project

FlightGear performance ( from: How can I retire from the forum?)

Questions about the FlightGear organisation, website, wiki etc.

Re: How can I retire from the forum?

Postby Thorsten » Sat Jul 05, 2014 6:41 am

Well, you know what?

After all that's been going on, I do feel the forum is no longer my place. I'll sleep over it in any case, but somehow there's relief in the thought.
Thorsten
 
Posts: 11375
Joined: Mon Nov 02, 2009 8:33 am

Re: How can I retire from the forum?

Postby junior-s » Sat Jul 05, 2014 6:47 am

Sorry, part of what I said was wrong, I admit it =]
I don't know the actual size of the scenery mesh. I can't speak about that.

I like the way Hooray stands up for the ignorance we end users commit sometimes. We don't need to point in "programmer details" what the problem is, it would be nuts to ask people to do so. And even though I've made mistakes in this thread, Hooray pointed aspects which confirmed what the users have been complaining for years. This is the kind of developer I want to be in touch with, the kind which can be around end users without trying to make other developers against an entire community because he's pissed off by the ignorance of a few.
junior-s
Retired
 
Posts: 212
Joined: Tue May 21, 2013 2:27 am
Location: Wonderland
Callsign: junior-s
Version: GIT
OS: Arch Linux

Re: How can I retire from the forum?

Postby Gijs » Sat Jul 05, 2014 9:33 am

Unfortunately discussion about "the future of the project" tend to get rather emotional. Sharing experiences and personal feelings is all fine, as long as we respect each other. Name calling is not part of that, so I've removed some recent posts. junior-s is now off the forum. I'd like to thank those posting interesting and constructive facts and experiences.

For future reference: just send one of the mods a message when you'd like to leave, so we can deactivate your account. For all other moderation related requests, please use the report system.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9391
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: How can I retire from the forum?

Postby Hooray » Sat Jul 05, 2014 1:17 pm

@Thorsten: I could go and respond to you quote by quote, but this isn't getting us anywhere - I based my statements on using tools that you don't consider necessary, and that you refuse to use. And I can reliably reproduce performance/resource utilization issues even without running/loading any scenery, in parts that have nothing to do with scenery or even rendering.

These kind of diagnostics you cannot obtain just from watching your system's process monitor (or even those OSG on-screen stats), you really need to look "under the hood".

And I stand by my sentiment that we're treating symptoms here, i.e. fixing things one by one (in this case TG/scenery), even though the same thing used to happen in other places of FG, some of which you are obviously aware of (e.g. Nasal/GC).

Somehow, you keep ignoring all I said in that context, and disregarding all the examples I provided - which is fine, but please do not expect me to continue this discussion as is, because it's obviously pointless, we've both been known not to be convinced easily in the past, and I guess this is simply one of these situations.

The test-case you are referring to is pretty narrow, which makes it useful to track down issues that don't depend on other factors like aircraft, AI and/or scripting - but obviously, there's not just a single issue.

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.

If you know about any way to obtain this kind of low-level information without using the tools that you refuse to use, I'd be intrigued to learn more.
But ´for now, we're obviously talking about hugely different things, and one of us refuses to accept that end-users may have a point, even without having to be familiar with FG internals and all the lingo involved.

You asked if I am seeing a pattern: Indeed, very much so - such as e.g. contributors refusing to accept valid feedback from less knowledgeable folks. But we've seen this in other instances, long before many current contributors showed up, such as:

  • the whole "multithreading for FG debate": http://wiki.flightgear.org/Technical_Re ... _Simulator
  • the request for a 2D rendering API, meanwhile addressed by Canvas, as you know
  • the request for an integrated FlightGear GUI front-end/launcher, meanwhile addressed by the upcoming Aircraft Center
  • the request for an improved multiplayer system (being addressed through HLA)
  • the request for better aircraft deployment (addresssed with Catalog metadata)
  • subsystem-level performance tracking, addressed via the system monitor

These are are just a handful of occurrences from the past, where non-coders (and often non-contributors) provided feedback and made requests, that were not exactly received very well among core developers, and where existing contributors would argue that people were mistaken and go to great lengths to prove their point.
Fast forward several years later, many of these have meanwhile become actual features.

Yet, each of those debates, which can be found in the archives easily, is very much along the lines of your responses here - disregarding the feedback for what it is, i.e. all potential merits.

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.

Again, I never said that any of those had to be integrated - I just said, that /we/ may have to use them at times, and that we should probably strive to OPTIONALLY provide certain diagnostics at run-time to enable end-users to provide us with better information/bug reports. It's the difference between having a systime() API in Nasal, and not having one: 99% of our users may never use it, but people like you, may use it to tell what's going on.

Finally, I couldn't care less - like a few others, some of us have provided patches to address some of the performance concerns, and to enable people to make more informed statements - still, those patches were never committed, and consequently we're seeing similar issues, in other parts of the program, being reported.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11475
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby adrian » Sat Jul 05, 2014 1:44 pm

When Hooray posts, it's like a volcanic eruption, you just don't know when it's going to stop :P
Otherwise 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.

Also, I strongly _feel_ that my name should be purple (with a shade of blue).
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: How can I retire from the forum?

Postby sa7k » Sat Jul 05, 2014 2:42 pm

zakalawe wrote:I’ve added some optional features to reduce memory consumption, and since ‘next’ is for testing, I’ve switched them both on by default in current Git. They are:
[ ... ]
Of course, the mose important test is if this makes the 2.0 scenery usable on 32-bit machines. I can’t perform that test, so hopefully some other people here can.

Sorry that this doesn't belong here but I read it here. 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.
sa7k
 
Posts: 382
Joined: Fri Mar 16, 2012 2:24 pm
Location: SA7K
Callsign: LV-EPM
IRC name: sa7k
Version: git
OS: debian

Re: How can I retire from the forum?

Postby Thorsten » Sun Jul 06, 2014 10:30 am

Yet, each of those debates, which can be found in the archives easily, is very much along the lines of your responses here - disregarding the feedback for what it is, i.e. all potential merits.



Either that.

Or people actually listen but reserve their own final judgement which doesn't agree with yours. Have different priorities from yours, don't agree with you where the limited manpower should be committed to first, see something problematic in a patch which you don't.

Just like I have responded several times to rendering issues that I recognize that there is an issue, but that I won't work on that with high priority. Or say 'That's a nice idea, but I'm not personally interested and wouldn't use such a feature, so someone else has to do it, I'd just help'. Which usually leads to outrage on the user-side, the same outrage seen from your side here. "FG would be in so much better shape if people only would have listened to MY insights how it really should be!", that's what your post says. If people would have listened to your opinion what patches are good and what feedback is valuable, we wouldn't have any problems. Because you have it all figured out and can judge in every instance whether a patch was rejected because it is genuinely bad, or because feedback is disregarded. Well - I can't judge. And at the end of the day, you can't either - you're been wrong a couple of times in areas where I have a solid understanding.

And yes - sometimes my judgement is wrong, and someone presents a convincing case that I need to do things differently. So I try to do better. Similarly I have seen Stuart and James try to do better and reverse their judgement when evidence came to light. So I have seen Vivian and Emilian try to do better.

But to construct from the fact that developers sometimes make wrong decisions (which as your list indicates even get reversed quite regularly) a general pattern of systematically disregarded feedback, that's a bit rich.

Yes, I also know some cases in which I would have decided otherwise and where I have argued otherwise. I can't for the sake of it understand what was so horrible about the radio propagation code for instance. But in the course of my FG years, I have worked with quite a few of the core developers. And they didn't strike me as the malicious types who refuse to listen to reason and throw away valuable info. So I'm prepared to trust that their judgement by and large isn't off by a huge margin, even if I can't see the reason myself because I lack the insight.

Well, I have to say, that really settles it for me.

I realize your case is going to be far more popular than mine, because we all want to believe that we've figured it out, and if other people would just listen, everything will be okay, even if we can't really back up our feelings with arguments. You're promising an utopia for everyone who is dissatisfied by the way things are going - because the project is allegedly structurally bad, and if that would be fixed, developers would code just what everyone wants to get out of FG, and we'd not have any problems.

And I'm trying to argue against utopia here, and I can't win that. I'm arguing that there are often sound reasons for listening to feedback and still decide otherwise - and that nobody wants to hear.

So I'll give up and leave the forum to you.

Bye.
Thorsten
 
Posts: 11375
Joined: Mon Nov 02, 2009 8:33 am

Re: How can I retire from the forum?

Postby punkepanda » Sun Jul 06, 2014 10:49 am

Good decision Thorsten. I guess its better to spend your time, training your OpenGL skills so us end-users can enjoy flying instead having all this personal and subjective discussion about stuff we dont understand
.
Probably better time spent for us all. Looking forward to what you add to the newsletters tough :)

Good luck and thanks for all the endless discussions in the past.
Last edited by punkepanda on Sun Jul 06, 2014 3:19 pm, edited 1 time in total.
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: How can I retire from the forum?

Postby Hooray » Sun Jul 06, 2014 2:31 pm

Thorsten wrote:Or people actually listen but reserve their own final judgement which doesn't agree with yours. Have different priorities from yours, don't agree with you where the limited manpower should be committed to first, see something problematic in a patch which you don't.


Actually, I am not the issue here - far from it, just look at discussions and developments that have taken place without any input/influence from my side.
You are doing an excellent job here misrepresenting what I said and using quite some manipulative language to get your point across, too.
It is fascinating how we keep being referred to by other as some kind of "sect", even though we're having so many clashes recently.


Thorsten wrote:"FG would be in so much better shape if people only would have listened to MY insights how it really should be!", that's what your post says

Sorry, that's just plain b/s - I couldn't care less about those features from my standpoint, because I can, and actually do, run tools to be able to make meaningful bug reports, and fix them along the way often enough. Like you, I find the number of poor bug reports frustrating - unlike you, I see a good option to address the issue in a generic way (without having to teach end-users how to use gdb, how to gather statistics in a meaningful way etc), and without being specific to a single issue, like -for the time being- TerraGear/v2.0 World Scenery complexity.

Thorsten wrote:If people would have listened to your opinion what patches are good and what feedback is valuable, we wouldn't have any problems.

Even more drama? I find it fascinating how this suddenly is all about me, and I am not sure I deserve all your attention here.

Thorsten wrote:And at the end of the day, you can't either - you're been wrong a couple of times in areas where I have a solid understanding.

Yes, and I am probably crediting you for those occassions fairly regularly - but I also realize that this is an important part of the dynamics involved here. We can start counting who's been right more often, and whose understanding -in which areas- is more solid, but I am really not interested in -yet another- pissing contest with you. We've had our fair share of them, and I know what they usually look like - you are making highly narrowed statements ultimately that must be true, while I am talking about general stuff.

Which is kinda summarizing the whole debate we're having here now - someone (you) is making this all sound it's v2.0 scenery, quoting others from the devel list in turn - without accepting, that we've had a number of similar issues, unrelated to scenery in the past.

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.

I am having a hard time seeing what's so difficult to understand about this point, and why people have to become so emotional about it?
And please don't get me started about the "possibly problematic" nature of an entirely optional patch.
This has zero to do with me at the end of the day - the patch was a response to a concrete issue we had back then. And I am not affected by it being applied or not. We're only having this debate now, because the two of us regularly try to help others with their "support enquiries" - unlike the majority of core developers.

Thorsten wrote:But to construct from the fact that developers sometimes make wrong decisions (which as your list indicates even get reversed quite regularly) a general pattern of systematically disregarded feedback, that's a bit rich.

I never said anything about "systematically-disregarded feedback" (or about "malicious core developers") - I just said that we don't generally act upon feedback immediately, and provided a few compelling examples for this being indeed being an issue.

I don't think it's fair to use your "cleverness", vocabulary and eloquence here to "systematically" misrepresent what I am saying, because I also stated quite clearly that I am guilty of this as well, and even provided a few examples and explained why this simply is the case often enough. I don't know what's so difficult to look at ourselves critically and see how we can improve - somehow, you are now admitting a few of these things, but apparently still perceiving my postings as an attack ?


Thorsten wrote:I realize your case is going to be far more popular than mine, because we all want to believe that we've figured it out, and if other people would just listen, everything will be okay, even if we can't really back up our feelings with arguments.

I think you know me well enough by now, and that I won't be impressed by the kind of "support" I am going to get because I'm -once again- disagreeing with you. Remember, I've been on boths sides of this. I find it unfortunate that you either completely -and genuinely- misunderstand what I said, or that you decide to misrepresent my postings by re-phrasing them and adding lots of drama to my statements and omitting important details.

Some of the postings here I also find unfair, especially "feedback" I am seeing in the rendering/visual department - but I genuinely believe that my postings were neithier impolite nor misrepresenting anything, and I also didn't naively suggest that I have the answer to all the issues at hand here - but for some reason you are using some pretty blunt tools now to terminate the whole thing and turn me into the problem - which isn't exactly fair.

And for that, I think I'd deserve resurrecting this whole thread 5+ years from now :lol: -hopefully- quoting our responses and pointing out that we actually implemented the functionality to get rid of such debates, by empowering end-users to "look behind the scenes" and make meaningful bug reports.


Thorsten wrote:So I'll give up and leave the forum to you.

lol, to me ? That's more drama from you in a single posting than I'm used to ;-)

I always found it unfortunate enough to see contributors leave the project in response to others, including people who stated that they'd leave because of you, and while I can foresee them now agreeing with your potential departure and me getting a few more PMs in turn, I still don't think that any user should be given the power to simply alienate others and make them leave the forum, or even the project.

(Which I never tried or even considered!)

If, on the other hand, it's for your own "sanity", then so be it: I've also contemplated taking a hiatus every now and then, and it does help to put things into perspective, and to make the whole thing enjoyable again.

For some reason, I am still having a hard time understanding why I am suddenly becoming the culprit here - why isn't it legit to look at a project in an objective way and criticize ourselves for things we could have done better ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11475
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby Philosopher » Sun Jul 06, 2014 2:43 pm

Criticizing oneself is an important part of being an even amateur musician after all ;) .... but really applicable to anything that involves progress that is, at times, unclear, difficult, and/or involves a lot of behavioral inertia in order to see results.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How can I retire from the forum?

Postby punkepanda » Sun Jul 06, 2014 3:49 pm

Hooray wrote in Sun Jul 06, 2014 2:31 pm:For some reason, I am still having a hard time understanding why I am suddenly becoming the culprit here - why isn't it legit to look at a project in an objective way and criticize ourselves for things we could have done better ?


Just take a closer look at my firsts posts on this forum about ALS colours and brightness long before the "Sky is too dark" thread and you will realize that you are not alone for getting all the "personal attacks" against you from the subject we speak of.

Thats whats happends if you give constrictive criticsm for something that could be better to someone manipulating it all around from being objective about a specefic issue, too becoming the "contributor involved's" worste enemy on this forum.

What if all that time crying about being "scientificaly / tecnicaly correct" all the time, would actually be spent on develop and improve things "quietly" before re-argumenting with people when he/she have already made up his mind about that person.

That is totaly waste of time for a developer when the project has limited manpower as it is. End-Users has a different standpoint;

They have the time to test and being subjective about things. End every question is legetime for a end-user as they only see the end result of the product. Even if they don't understand all what's going on under the hood, does not nececerly mean they are all wrong about things that can improve a lot.

It's good to have Hooray here to front all the end-users on the forum. He does a great job with hes quick response time with feedbacks on any question, no matter how "stupid" the questions may seem.(even he also can be a little to personal at times). But we learn as we walk :P

BTW.. Hooray, I never ment to put your head in the "sect" bucket. I trying to make a point about how easy it is to jump on the "subjective" wagon and discredit newcomers(as myself) for not have the same insight as the etablishment of long time contributors here . And it was not directed to you in any way..So I really apologize to you if I was to be understood that way. Please try not to take it personal by being personal yourself. Thats the big trap along with repeating sarcasm.. I know you can do better because I've seen it from you ;)
Last edited by punkepanda on Sun Jul 06, 2014 8:09 pm, edited 6 times in total.
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: How can I retire from the forum?

Postby Hooray » Sun Jul 06, 2014 4:01 pm

@Philosopher: Yeah, I think that sums it up pretty well, we need to be able to look at ourselves and our performance and see how we can improve over time, and we can avoid certain time-wasters, such as this debate - or even just the plethora of non-actionable bug reports.

Don't get me wrong: I am also not amused when I see dozens of users attacking individual contributors (or their features, like ALS or even Rembrandt!), and I also find it problematic that people tend to use poor wording/language and lack basic courtesy skills.

But at the end of the day, we can at least try to look at feedback regardless of its nature, i.e. just in terms of the key message - such as, in this case, users who have been complaining that they can no longer run the "product" and that they're seeing resource utilization issues, especially on old hardware, i.e. CPU/GPU and RAM/VRAM and related segfaults.

Thorsten and I, well, we're both sitting in front of hardware worth $2k-3k US (~18 months ago), with ~10+ gb of RAM, 2 gb of VRAM, 8 cores etc and I'll be the first to admit that this may very well kinda "mask" such issues, and that end-users may run into issues that we may not perceive as critical, or that we may never even notice at all.

It is true that probably 99% of our end-users will not find the proper technical terms, and that they usually find the wrong cause and suggest the wrong solution to a particular problem, but that's why we have contributors here who can process, filter and analyze such discussions, to get to the meat of the problem.

This is not some random/uninformed bug report like "ALS is too reddish" or "Rembrandt is too slow" - it is about a key issue that may affect many people, and that even regardless of its manifestation, would -if address- benefit the community as a whole, i.e. better bug reports, more focused optimizations etc

Right from the beginning, I suggested that we shouldn't restrict our focus to a single cause (like v2.0 scenery in this case) but look at the bigger picture, i.e. what needs to be done to identify certain issues earlier (regardless of their manifestation), but also to enable non-contributors to make better, and more informed, bug reports.

For instance, a few people like Zakalawe and TheTom have been working towards this, e.g. as part of the whole crash reporting framework, which I understand submits data via HTTP.
Our bottleneck now is 1) processing power (that is, volunteers willing to help review things) and 2) lack of additional information that would help us narrow down things, as summarized at: http://wiki.flightgear.org/Towards_bett ... leshooting

This doesn't automatically give us better bug reports, but it enables more experienced contributors to triage bug reports and use the bug tracker accordingly, and yeah, I am volunteering to help with this - exactly like I did 4+ years ago.

Discussions on run-time stats/diagnostics to track CPU/GPU/RAM/VRAM utilization are likewise not going to magically "fix" any issues, but implementing the actual feature means that less-experienced contributors can provide more informed bug reports, without having to spend a ton of time. It is a huge game changer if people can access a "process monitor" and see where their horsepower is spent, even regardless of scenery/rendering, as per ThorstenB's comments when he first implemented the "performance monitor":

http://www.mail-archive.com/flightgear- ... 34886.html
ThorstenB wrote: this alone isn't improving anything yet, but having a GUI to
conveniently monitor performance will hopefully help us to see where
exactly we're having issues - and help us to improve...


Once this infrastructure is in place, we could use cmake's ctest infrastructure to do automated regression testing right on the build server, i.e. by playing back a handful of pre-recorded flights/flight recorder tapes with different settings (rendering, LOD ranges) and tracking resource utilization, which would enable us to keep track of potential issues even across release cycles.

For example, when I recently updated the "minimal startup profile" section on the wiki, I found that on the same old laptop my max frame-rate decreased from ~700 fps to ~500 fps within ~12 months, e.g. 5/7 and RAM utilization increased by 150 MB (same computer, gpu, distro, cpu, ram etc!):
FG 3.2:
Image
FG 2.12:
Image

Image
The only things that changed since then were 1) SG/FG, 2) OSG and 3) the NVIDIA driver.

It's these kind of statistics that we should strive to provide at run-time, so that we can enable others to more easily identify potential issues.
And people who build from source can then at least decide if they want to check individual subsystems (just watching per-process memory isn't exactly helpful when it comes to the actual C++ code)

Funnily, I found this to be related to two things 1) the newer OSG and 2) the newer GPU driver - especially reverting the latter would give me +80 fps again.

On the devel list, people actually were discussing -once again- feature scaling:
http://sourceforge.net/p/flightgear/mai ... /32445574/
Rebecca wrote:I'd consider the long-term solution to be some kind of detailed close
in/simpler further away terrain mesh scheme (either two resolutions on
disc or simplified on the fly), preferably with a way to automatically
adjust the draw distance/quality based on available memory


Which is exactly what we're discussing 2-3 years ago (which kinda proves the point that we don't usually act upon feedback immediately, including myself):

Subject: Random Buildings
Hooray wrote:exposing internal stats to the property tree would still seem useful, especially for people wanting to make bug reports, or even just for dynamic "feature-scaling" using Nasal and/or XML-Property Rules. Thus, I feel that even just replacing the SG_LOG() statements with SGPropertyNode->setStringValue(...) would be a good move, as it would help people looking "under the hood" of the system, so to speak.

And like I said earlier, being able to control the behavior of the system (even if that just means disabling/enabling allocations) would definitely be useful to see if segfaults/crashes reported by users can even be remotely related to the new system or not. If we had this option now, it would be much easier for us to provide support to the users here seeing "OpenGL out of memory" errors.

All that aside, your earlier comments regarding "swapping" all still hold true - Thorsten just confirmed that this is also what "kills" FG for him: http://flightgear.org/forums/viewtopic. ... 34#p164933

In other words, I do think that it would be worthwhile to keep this in mind and possibly really come up with a subsystem that monitors FlightGear's RAM usage at configurable intervals of say 1-5 seconds, and dumps all the info to the property tree, where it can be further processed by Nasal scripts or GUI listeners. If it's really swapping that slows down or kills FG for so many people, we obviously need to prevent it - and having access to real time memory usage stats would definitely seem useful then - not just for the random buildings system, but also all other subsystems that may "over-allocate" and run into swap space.

Thus, even just having a boolean "/memory/swap/is-swapping" would be useful, because other subsystems could monitor it using a listener and then adjust their own allocation behavior dynamically.

EDIT: I can handle the Linux implementation of this ...


I think fellow contributors should really be allowed to look at our "performance" (as a project) and reconsider past discussions, and look at how to improve things in the long term.
It is for a reason that I am so frequently updating the wiki, and e.g. created articles like the "troubleshooting" article that's seen 12+k views meanwhile: I don't want to deal with all these support enquiries, and I want to see these problems understood and addressed - these conversations and debates are rarely constructive unfortunately, but given the number of views, it is obvious that there's an audience, and thus, a problem here.

Again, I couldn't care less about TerraGear or the v 2.0 scenery - maybe in a few years, people will all be using Rembrandt or maybe most people will use osgEarth - who knows...

I am really only interested in finding a solution that generalizes and scales (without it being specific to a single subsystem that is explicitly optimized), i.e. that allows us to identify such issues earlier, and to better understand them - hopefully enabling end-users to provide better bug reports.

If 5 years from now, performance issues are scenery related, related to Nasal/Canvas or whatever else, shouldn't matter at all - as contributors, we should really only strive to provide the diagnostics to enable less-experienced contributors to draw proper conclusions and make more informed issue reports, no matter if the original developers of the corresponding code are still around or not - imagine for a second we would no longer have people who understand Nasal internals, Canvas, Rembrandt etc - we'd still want to ensure that there are means to tell what's going, without having to be a highly experienced C++ developer.

It is for a reason that even trivial applications, like your browser, have a "process/task" monitor built right into program.
The type of info posted on the devel list is really just the beginning, and it is too unspecific to be useful - i.e. FlightGear's run-time behavior is hugely different once you keep it running for a few hours, depending on the features and settings you're using - you'll see memory gobbling up (and even leaking) regardless of scenery - that is where more experienced developers need to use the right tools to gather more detailed data.

It's not something I'm just saying or requesting, it's something I've been doing for years, not just by posting profiling info here, but also by providing the patches to gather the corresponding - some of which got integrated, others didn't - but I am not offended by it, not even by this debate - I find dealing with 50+ support threads more tiring than discussing methods to hopefully optimize our workflow in the mid-term.

And yes, that entails criticizing ourselves, including myself, for past performance and looking for ways to address such issues over time :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11475
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby Prometeo 2013 » Mon Jul 07, 2014 4:36 pm

I know that the debate is closed , but this is my opinion, please see the image.
https://flic.kr/p/ocTyXf
Prometeo 2013
 
Posts: 22
Joined: Wed Jun 18, 2014 11:43 am
Callsign: Prometeo2013
OS: windows 8.1

Re: How can I retire from the forum?

Postby Hooray » Mon Jul 07, 2014 4:59 pm

while 4.4gb may seem like a lot, it obviously depends on your startup and run-time settings, so without any additional information, it's hard to say if there's anything wrong here or if we could do better to preserve RAM. Also keep in mind that this is all of the mapped memory, including GPU-mapped VRAM, so not all of it is system RAM if I interpret those Windows stats correctly. 2.7 gb is basically what can be expected with the default settings and v2.0 scenery, even though it may increase pretty quickly once you use a complex aircraft and fly around for a while (via AP/RM or flight recorder). While this is also to be expected, there are a few leaks, and also subsystems that are unconditionally added without being strictly required in all cases - some of those are XML-configurable, others are hard-coded still.

Thanks for turning this ridiculous thread into a constructive discussion again - but as can be seen in the stats posted by all people using their system's process/task monitor, those stats do not tell us exactly what's going beyond just RAM utilization as a whole - so all conclusions drawn are directly linked to 1) scenery/location in use and 2) aircraft in use - without anybody here having any way to tell directly which parts of the aircraft/scenery (tiles) are really contributing how heavily to overall RAM utilization.

And like I said earlier, even total RAM utilization per subsystem is just one attribute obviously.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11475
Joined: Tue Mar 25, 2008 8:40 am

Re: How can I retire from the forum?

Postby adrian » Mon Jul 07, 2014 5:21 pm

I don't think it's fair to blame any particular subsystem for these issues. The fact is, the project has to keep evolving and transforming in order to remain relevant, and this means things can sometimes break in the process, regressions rear ugly heads, some users become unhappy, but overall the project is moving forward and commits are regularly made by core contributions, which I think at some point becomes essential to maintain confidence in the future of the project, as we can see in many other open-source code bases, rather than stagnate and become increasingly irrelevant in today's fast moving market, as it's never a good idea to throw away perfectly good opportunities for progress, even though it could inspire distrust and even drive away some potential users, as long as the core contributors are kept reasonably satisfied and are not compelled to move away from the project.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest