Variable scope, removal and performance

Solar2D General Questions/Discussion
#1

I have read the great tutorial by Jonathan Beebe about properly removing variables, but there is one thing I still don’t understand. Does it make any difference from a performance/cleanup standpoint if I declare a local variable (holding something other than a display object, like an alpha numerical value) inside or outside a function?

In the tutorial it says:

“Local variables get cleaned up automatically at the end of their block of code. What that does not mean, however, is that if you create an object within a small, isolated block of code, that the object will be removed at the end of function execution. Actually, this is a pretty bad situation as the object will remain, but the local variable will be cleared away and you’ll have no way to access the object (which hinders you from being able to remove it later on).”

I that also true for variables NOT holding a display object? In other words, will the variable myAlphaNum also be “created and abandoned” in the function below?
 

local function create\_and\_abandon() local outcast = display.newImage( "image.png" ) local myAlphaNum = "AA23" outcast.x, outcast.y = 160, 240 end
#2

I suppose it might, but not completely sure.  However, it really doesn’t matter.  There will be no observable performance difference.

#3

No.  It’s a little confusing because there are two different things going on.  One is the creation of CoronaSDK objects (like Images) which persist until they are explicitly removed and the other is the creation of Lua objects (tables) to reference those objects.  While closely connected these are different items in the program’s memory.

In the example above the call to display.newImage() requests that a new Image object be created and a table for it be returned (which is then saved in “outcast”).  Unless an Image object is explicitly removed (by calling removeSelf() on it) it will continue to exist until the program exits even if the variable referencing it, “outcast”, no longer exists.  “myAlphaNum” however is a simple Lua string which will be destroyed when the variable goes out of scope (at the end of the function in this example).  Numbers, strings, bools and tables are all simple Lua types.

The particular case that the linked article is talking about is when removeSelf() is called on an object but the variable referencing it isn’t destroyed.  This can cause memory to be used unexpectedly.  The best approach is generally to keep the scope of variables as small as possible (by declaring them locally in functions and blocks) but this can be hard as program complexity grows.  More info can be found here http://lua-users.org/wiki/ScopeTutorial

#4

Excellent, thanks!

#5

I suppose it might, but not completely sure.  However, it really doesn’t matter.  There will be no observable performance difference.

#6

No.  It’s a little confusing because there are two different things going on.  One is the creation of CoronaSDK objects (like Images) which persist until they are explicitly removed and the other is the creation of Lua objects (tables) to reference those objects.  While closely connected these are different items in the program’s memory.

In the example above the call to display.newImage() requests that a new Image object be created and a table for it be returned (which is then saved in “outcast”).  Unless an Image object is explicitly removed (by calling removeSelf() on it) it will continue to exist until the program exits even if the variable referencing it, “outcast”, no longer exists.  “myAlphaNum” however is a simple Lua string which will be destroyed when the variable goes out of scope (at the end of the function in this example).  Numbers, strings, bools and tables are all simple Lua types.

The particular case that the linked article is talking about is when removeSelf() is called on an object but the variable referencing it isn’t destroyed.  This can cause memory to be used unexpectedly.  The best approach is generally to keep the scope of variables as small as possible (by declaring them locally in functions and blocks) but this can be hard as program complexity grows.  More info can be found here http://lua-users.org/wiki/ScopeTutorial

#7

Excellent, thanks!