Posted on by

Corona GeekThis week we hung out with Ed Maurina, Gerald Bailey, Jesse WardenMatthew Chapman, and Richard Harris to discuss memory management in Corona SDK. Ed did an excellent job of explaining the sample app he created after one of our previous Hangouts where we discussed Storyboard. His app demonstrates how memory is affected when objects are set to nil at various stages of development. Ed agreed to post his code on GitHub, so we’ll post a link to his code once that is available. We also talked about the announcements at Google IO, the ongoing Dilbert contest, and COPPA Privacy Policies.

Corona Labs T-Shirt Winner

Congratulations to Theo Rushin, Jr. for winning this week’s Corona Labs’ t-shirt. For your chance to win, follow Corona Geek on Twitter and Facebook, and complete the Corona Geek giveaway form.

Thank you for watching, we’ll see you on next week’s Corona Geek hangout!

Remember To Subscribe


Posted by . Thanks for reading...

7 Responses to “Corona Geek #40 – Memory Management, Google IO, and Dilbert”

  1. Derek J

    Very informative(and timely) I was just starting to tinker with storyboard and memory management. Any chance we can get a link to the test app code that was used?

    Reply
    • Derek J

      As an aside,I was unable to submit a comment without putting in a website, though the form doesn’t have it labelled as required.

      Reply
    • Charles McKeever

      Hi Derek J. Thank you for watching the show. Ed should be publishing the app soon. A link will be added to the post when it’s ready.

      Reply
  2. Ed Maurina

    Hi. This is a quick summary of how the the sample code (CoronaGeekAfterTalk.zip) came about and what it does.

    How the Code Came About
    ====================
    On a prior CoronaGeek hangout, the following questions where raised:

    Question #1 – What happens (when using storyboard) if I have local references to objects in the scene and then scene is purged? Do the local references get cleaned up or do I lose that memory?

    Question #2 – Is there and easier/better way to handle local references to objects in a storyboard scene?

    Question #3 – If I create display objects and add event listeners, do I have to remove them later or will the listeners be automatically removed when the objects are destroyed/removed?

    Initially, my answers were:

    #1 – No, the local references are not cleaned up. That memory gets lost.
    #2 – Yes, there is a better way than using locals. Store handles to objects on the scene’s group object.
    #3 – Not sure. I think you used to have to removed the listeners, but that may have changed.

    After the show, I thought, “Hmmm… I should test my answers out.” So, I spent a little time and cobbled together the app found in CoronaGeekAfterTalk.zip.

    What the Code/App Does (and how to use it)
    =================================
    The code in CoronaGeekAfterTalk.zip contains six (6) sample scenes that do the following:

    1. Creates a blank scene (almost no content) to show how much memory is used for a (mostly) empty scene.

    2. Creates a scene with about 23,000 image and stores a reference to every image in the table ‘imageHandles’. Then, when the scene is purged in scene:destroyScene(), that table is set to nil, effectively nil-ing the references.

    3. Same thing as #2, but does not nil the table.

    4. Same as #2, but instead of a local table, attaches the table to the group provided by the storyboard scene manager (see scene:createScene() and scene:enterScene()). This table will be automatically removed when the group is removed by storyboard. The important thing to understand about this example is that, we can reference the object references any time, but we no longer are responsible for nil-ing them out.

    5. In this sample, I created 23,000 images and attached a uniquely generated event listener function to each one. I did this to take up as much memory as possible. To be clear, every object has its own touch function and the objects are not all sharing a single function which would be the efficient way to do it. In this example, when the purge happens, I remove all the listeners by iterating over the image handles and calling ‘obj:removeEventListener()’.

    6. Same as #5, but I do not remove the event listeners manually.

    Please note: #5 and #6 use the ‘improved’ handle tracking technique from #4. i.e. Automatic nil-ing when the scene is purged.

    To run the samples do the following:
    1. Load it in the simulator.
    2. Observe the main memory and texture memory ‘in-use’ values while at the main menu.
    3. Click one of the 6 sample buttons to run that sample.
    4. Observe the main memory and texture memory ‘in-use’ values while running the sample.
    5. Click the back button (all scenes have one).
    6. Observe the main memory and texture memory ‘in-use’ values while at the main menu.

    At this point, you should be able to see the following:

    - The memory has been (mostly) cleaned up and is the same as when we started,

    OR

    - The memory has not been cleaned up.

    You can re-run the tests as often as you like, but I suggest restarting the simulator between different scene tests.

    Final Results
    ==========
    Question #1 – Correct. The local references are not cleaned up and there is a memory leak.

    Question #2 – Interesting. Most of the memory is cleaned up, but a little bit of memory is consistently NOT cleaned up. However, there is no leak. For some reason, Lua is defering the memory clearing and free space coallescing.

    Question #3 – Interesting and awesome. Corona is clearing the memory associated with the listeners automatically when the objects are deleted. This makes coding that much faster and easier.

    Final Notes
    =========

    I forgot to mention this, but in mainMenu.lua, you will notice that everytime we enter the scene I call ‘storyboard.purgeAll()’ to force the removal of all non-active scenes. If I did not do this, this app would not do any memory cleaning because I have plenty of memory to hold the inactive scenes in memory.

    Reply

Leave a Reply

  • (Will Not Be Published)