Clarification Needed on: "Cleaning Up Display Objects and Listeners"

Solar2D General Questions/Discussion
#1

From Rob Miracle’s “Cleaning up Display Objects and Listeners” :

"Be Careful…

Local references to functions are nil’ed out when the function ends. That is, they only live for the time that the function is executing. These will be cleaned up for you.

Where you can create a small memory leak is if you do this:

local enemy local function spawnEnemy() enemy = display.newImageRect( "badguy.com", 64, 64 ) return enemy end function scene:createScene( event ) local group = scene.view local background = display.newRect( 0, 0, display.contentWidth, display.contentHeight ) group:insert( background ) local doSomething = display.newImageRect( "button.png", 64, 32 ) group:insert( doSomething ) for i = 1, 100 do group:insert( spawnEnemy() ) end end  

Similar to the first example, the enemies will all be cleaned up when Storyboard destroys the scene, however the “enemy” variable will stick around until the scene is “un-required.”  "

1st:

What is meant by “local references to functions”?

    Could you provide an example? ( Are we talking about forward declarations?)

 

2nd :

In the example above, are you suggesting (as a best practice) that all forward-declared items (including functions, etc.) should be nil’ed out upon scene exit ?  

Or, is it just safe to wait until the module unrequired manually or automatically?

 

3rd: 

When something (anything) is forward-declared, is it entirely prevented from being removed from memory, or is it just a leftover variable that needs to be nil’d?

 

i.e. , If Storyboard removes a forward-declared display object via its master group, would the forward declared variable be all that remains (and thus all that needs to be nil’d out)? 

#2

Any ideas?

#3

1.  That’s a typo I think.  It should read: 

Local references in functions are nil’ed out when the function ends

The change in that little world means something different.  If you declare a local inside a function, that variable only exists for the life of that function. When it returns, any local variables go away.  Allocated object memory won’t, but in this example, the “doSomething” object is a table and that table contains pointers to the image, to it’s helper functions etc.  When the function ends, the little bit of data that makes up that object/table is gotten rid of.

2.  You don’t deal with the functions.  Leave them alone.  What you might want to do, is if you look at the example where “enemy” is declared local in the main chunk.  It gets used inside a function, so that bit of table holding the helper functions and the pointer to the data hangs around even though Storyboard frees up the data.  You’re left with a little allocated memory, so nilling it (since it’s in the main chunk and doesn’t get freed up since it’s not inside a function) will save a little memory, but as soon as you come back the memory is bacl.  It doesn’t really “leak” since the amount of memory won’t go up by not nilling it.  You can safely leave it alone, but if you want to be hyper vigilant you an nil it. 

3.  Forward declared variables hang around until the module is “un-required” (i.e. storyboard.removeScene()).  They will not be re-initialized if the scene gets called again.  If you’re coming back and the variables don’t need to be reset, you can leave them be. 

#4

  1. Yeah, now that you use the word “in,” it confirms what I already knew! Thanks for the clarification and reiteration though. 

  2. Good to know about functions, I’d figured as much, but I wanted to be absolutely sure since the initial wording had me doubt said handling of functions, with references “to” and such. Still valuable information though, I’m glad to know that now. Thanks here too. 

  3. Okay, since I tend to destruct a module/level upon exit, I’ll leave said variables be (since the module will be unloaded anyhow).

Thanks again for the very prompt and clear explanations. I’m very relieved! 

#5

Few more questions. Say I store references to objects in a table/array.
 
Does niling out a table, nil out all its keys?
 
(or)
 
Must I do both upon scene exit (keys and then the table itself) ?
 
Finally, when a module is unloaded are tables automatically cleaned up?

#6

Any ideas?

#7

1.  That’s a typo I think.  It should read: 

Local references in functions are nil’ed out when the function ends

The change in that little world means something different.  If you declare a local inside a function, that variable only exists for the life of that function. When it returns, any local variables go away.  Allocated object memory won’t, but in this example, the “doSomething” object is a table and that table contains pointers to the image, to it’s helper functions etc.  When the function ends, the little bit of data that makes up that object/table is gotten rid of.

2.  You don’t deal with the functions.  Leave them alone.  What you might want to do, is if you look at the example where “enemy” is declared local in the main chunk.  It gets used inside a function, so that bit of table holding the helper functions and the pointer to the data hangs around even though Storyboard frees up the data.  You’re left with a little allocated memory, so nilling it (since it’s in the main chunk and doesn’t get freed up since it’s not inside a function) will save a little memory, but as soon as you come back the memory is bacl.  It doesn’t really “leak” since the amount of memory won’t go up by not nilling it.  You can safely leave it alone, but if you want to be hyper vigilant you an nil it. 

3.  Forward declared variables hang around until the module is “un-required” (i.e. storyboard.removeScene()).  They will not be re-initialized if the scene gets called again.  If you’re coming back and the variables don’t need to be reset, you can leave them be. 

#8

  1. Yeah, now that you use the word “in,” it confirms what I already knew! Thanks for the clarification and reiteration though. 

  2. Good to know about functions, I’d figured as much, but I wanted to be absolutely sure since the initial wording had me doubt said handling of functions, with references “to” and such. Still valuable information though, I’m glad to know that now. Thanks here too. 

  3. Okay, since I tend to destruct a module/level upon exit, I’ll leave said variables be (since the module will be unloaded anyhow).

Thanks again for the very prompt and clear explanations. I’m very relieved! 

#9

Any ideas?

#10

If your table has references to display objects, timers or transitions, you probably should remove/cancel them individual before nilling the table.  If the table does not contain allocated memory objects like those above (audio handles too), then nilling it will clear everything out.

#11

Thank you very much. I’m all about taking care of the foundation!

So, would this process be acceptable?

  1. Remove allocated memory objects via display.remove(), timer. cancel(), etc. 

  2. Nil the table that contained the references

(all keys within the table will be taken care of by nilling the table itself, I assume, and there is no need to deal with the keys individually? )

#12

Few more questions. Say I store references to objects in a table/array.
 
Does niling out a table, nil out all its keys?
 
(or)
 
Must I do both upon scene exit (keys and then the table itself) ?
 
Finally, when a module is unloaded are tables automatically cleaned up?

#13

Any ideas?

#14

If your table has references to display objects, timers or transitions, you probably should remove/cancel them individual before nilling the table.  If the table does not contain allocated memory objects like those above (audio handles too), then nilling it will clear everything out.

#15

Thank you very much. I’m all about taking care of the foundation!

So, would this process be acceptable?

  1. Remove allocated memory objects via display.remove(), timer. cancel(), etc. 

  2. Nil the table that contained the references

(all keys within the table will be taken care of by nilling the table itself, I assume, and there is no need to deal with the keys individually? )