Thorsten is a great developer of OpenGL code and is doing a wonderful job with the ALS! But I believe that many problems that complain of FGFS are due to problems that can be solved. Meanwhile I want to anticipate that the developer EFA (Eurofighter), reading
this post has analyzed more carefully the code NASAL and found that the problem was related to an error in the NASAL code.
Did you read what I wrote? Did you check the numbers? Did you read what you yourself wrote?
I'm sorry, but that's just voodoo - you deactivated the Nasal subsystems of the plane and found no effect, so now you're anticipating that the developer will analyze the Nasal and find a problem? Based on what - that it didn't have an effect for you? Based on the small performance footprint of the events subsystem you plotted?
Whether I am a great GLSL coder or doing a crappy job is completely irrelevant for the question at hand (incidentially, I'm also one of the most experienced Nasal coders - AW is completely Nasal based). What matters here is that in order to solve problems, we have to follow where the data leads, not blame random subsystems.
1) So far, we're lacking hard evidence to prove that this is related/unrelated to Nasal
It persisted after de-activating the Nasal subsystem. We had a report NASAL code does not seem to be the cause, because it was all off. We have the performance monitor plots in addition. They all agree with my understanding how FG burns framerate based on my own performance tests.
I don't know about anyone else, but in my book that counts as evidence.
Not knowing much about fg coding in general, just generally speaking, a scripting language is not very efficient. So i wonder why fg leans so heavily on a scripting language like nasal.
Because if you have a task that consumes 0.01% of the total computational performance, it doesn't matter whether you do it efficient or inefficient - if you make it ten times faster, the framerate won't move a bit, and if you make it a hundred times slower, the framerate won't move either. Given that, you can priorize accessibility and ease of maintenance over execution speed.
(To give you a sense of perspective - the typical Nasal subsystem runs a couple of hundred lines per frame. Rendering at high quality runs about 1500 lines for each of your two million pixels every frame and loops over an array containing a good million vertices). That's about a factor of thirty million more operations per unit time. So FG doesn't lean 'heavy' on Nasal in terms of where the work is.
GLSL is the opposite case - that's where 99% to 99.9% of the computational cycles happen, so if you make it 20% faster, the framerate actually moves by 20%. Which is why rendering code frequently isn't accessible,but rather ugly and highly optimized.
Having said that, you can of course misuse Nasal to do heavy computing duty, in which case it eventually will slow down FG (if you inspect Nasal arrays with millions of entries every frame, it won't be a tiny amount of computation any more). But as long as you use Nasal for things that are not heavy-duty work (i.e. involving loops over thousands of entries, running code triggered by hundreds of listeners at the FDM rate...) the above argument holds.
The bottomline is - you need to optimize framerate by optimizing the part of the code where most performance is burned. Targeting subsystems with insignificant performance is pointless for optimization (still nice conceptually though...).