Variables management

[clm76]

Hi,
Question about the management of variables in Fg.
For example :

Code: Select all

var update : func {
   var test = 1 ;
   settimer (update,0) ;
}


Is the same variable « test » used in every passage in the loop and so only one variable is created in memory or is another variable with the same name which is stacked in memory in every passage in the loop ?

My question is to solve a problem of free memory which decreases over time, and frame rate too, when my aircraft is flying. It’s very sensitive after 1 hour of flight where the flight becomes jerky.

[Thorsten]

In this case, you're initializing a new one every loop - but they don't accumulate, the infamous garbage collector ought to take care of the unused copies.

[Hooray]

Thorsten is correct - however, if you are seeing dropping RAM/performance over time that seems specific to certain Nasal code, that's usually to do with other resource leaks - the most common mistake that people tend to make is to misuse timers and listeners in a fashion that the corresponding callbacks get registered to be invoked too often/too frequently, at which point you'd see memory gobbling up and performance dropping over time.

It is unfortunately fairly easy to make these mistakes, and there is no good method available at runtime to determine how often a certain callback is actually called or requested to be invoked. We covered that extensively on the forum, and I ended up implementing a patch that basically use the address of the pointer and the Nasal file/line number to "identify" where a callback was registered.



viewtopic.php?f=30&t=28675


Some background info can be found below:
viewtopic.php?f=4&t=28542&p=274617&#p274617
http://wiki.flightgear.org/Towards_bett ... ting#Nasal
http://wiki.flightgear.org/Using_listen ... with_Nasal

viewtopic.php?f=30&t=28084
http://wiki.flightgear.org/Resource_Tra ... FlightGear

[clm76]

Thanks to Thorsten for his reply.

@Hooray,
I'm reviewing all the listeners, settimers and maketimers and loops I used.

I ended up implementing a patch that basically use the address of the pointer and the Nasal file/line number to "identify" where a callback was registered.

Is this patch corresponding to your screenshot and is it the code found in http://wiki.flightgear.org/Howto:Troubleshooting_Nasal_Callbacks ? If it is, it returns an error "empty subexpression in /home/.../Nasal/callbacks.nas line 43".

[Hooray]

For starters, my suggestion would be to use global variables that are incremented/decremented whenever the callback is registered to be called or actually called, and then dump that info to the console, to see if your callbacks are getting invoked more often than you were intending, for example (untested pseudo code):

Code: Select all

var counters = {c1:0, c2:0, c3:0};

var callback1 = func() {
counters.c1 += 1;

counters.c1 -= 1;
};

var callback2 = func() {
counters.c2 += 1;

counters.c2 -= 1;

};

var callback3 = func() {
counters.c3 += 1;

counters.c3 -= 1;

};




[clm76]

For starters, my suggestion would be to use global variables that are incremented/decremented whenever the callback is registered to be called or actually called, and then dump that info to the console, to see if your callbacks are getting invoked more often than you were intending,

Yes, it's my method to debug loops.