I noticed an ugly issue with many of our Nasal modules. Not sure if 
that's a result of changed behaviour years ago, or it's just a common 
copy & paste issue that just wasn't noticed so far.

Problem is, lot's of Nasal modules listen to the property
to trigger some initialization code. It's fine to do so. However, 
modules need to be aware that this signal triggers on _every_ simulator 
reset. So, the connected code executes every time you hit Shift-ESC, use 
the "Relocate-in-air" or "Relocate-on-ground" dialogs.

We had plenty of places were init code connected to 
"/sim/signals/fdm-initialized" installed a fresh set of listeners or 
started another timer-driven update loop. This results in performance 
degrading with every sim reset.

The "worst case scenario" looks like this:

_setlistener("/sim/signals/fdm-initialized", func {
     setlistener("/sim/foo", foo);
     setlistener("/sim/bar", bar);

var update_loop = func {

=> Initially 'foo' and 'bar' are called once whenever their respective 
listener triggers. After the 2nd sim reset, they are called twice per 
change, after the 10th reset they are called 10 times for each property 

Similar issue with "update_loop": initially there's only one timer 
running. After the 10th reset, there's already 10 concurrent loops...

I've fixed the issue in several places of our generic Nasal modules (so 
this affected every aircraft). I've also fixed the issue for the C172 
and B777 specific Nasal code. These aircraft are fine now - no 
performance drop even after many sim resets. But I guess many more 
aircraft suffer the same problem.

Anyway, if you ever wondered why performance is so bad with FG2.0-2.6 
(not sure about earlier versions) after resetting the sim or relocating 
the aircraft multiple times, you now know why ;-).


This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Flightgear-devel mailing list

Reply via email to