Optimisation GC related question for masters

Hey guys, I got a question not sure how exactly the GC perform as my game lags a bit over long period of time.

Please see if there is any memory leak with the following code or if there is anything I can do to improve it.
local list = {}
local counter = 0
local function render( event )
counter = counter + 1
local graphic
if counter == 5 then
graphic = display.newImage(“agraphic.png”)
graphic.randomAttribute = “SOMETHING”
list[#list + 1] = graphic
counter = 0
end

local i = 1
while i <= #list do
graphic.alpha = graphic.alpha - 0.1
if graphic.alpha < 0.2 then
graphic:removeSelf()

– Do I need to set graphic to nil ? Does graphic go get GCed after table removes it?
– Do I need to set randomAttribute to nil or would that make the whole graphic to persist in memory even if table removes it?
table.remove(list, i)
i = i - 1
end
i = i + 1
end
end
Runtime:addEventListener(“enterFrame”, render) [import]uid: 6066 topic_id: 2162 reply_id: 302162[/import]

Heh, I’m no master but I think the following doc will answer your questions:

http://developer.anscamobile.com/content/memory-management-changes-corona-sdk-beta-8

To quote: “…rendering-related resources of the removed object are deleted immediately. What remains of object is simply a plain Lua table with all non-display object properties (the metatable is set to nil and all properties relating to display object are removed). Thus, if there are still references to object in Lua, they will simply be references to a normal Lua table.”

The ‘Before and After’ code samples in the document should make this more clear.

Tim
[import]uid: 8196 topic_id: 2162 reply_id: 6457[/import]

Highlighted the syntax for easier reading.
[lua]local list = {}
local counter = 0
local function render( event )
counter = counter + 1
local graphic
if counter == 5 then
graphic = display.newImage(“agraphic.png”)
graphic.randomAttribute = “SOMETHING”
list[#list + 1] = graphic
counter = 0
end

local i = 1
while i <= #list do
graphic.alpha = graphic.alpha - 0.1
if graphic.alpha < 0.2 then
graphic:removeSelf()

– Do I need to set graphic to nil ?
– Does graphic go get GCed after table removes it?
– Do I need to set randomAttribute to nil?
– Would that make the whole graphic to persist
– in memory even if table removes it?
table.remove(list, i)
i = i - 1
end
i = i + 1
end
end

Runtime:addEventListener(“enterFrame”, render)[/lua] [import]uid: 6066 topic_id: 2162 reply_id: 6504[/import]

Hey Tim,

Thanks for the link. I read that doco again but I think it does not yet answer my area of unsureness~!

I know that post Beta-8, when removeSelf is called, and rendering related data such as ‘x’, ‘xScale’ etc are all removed as well as the graphic itself. However, the rest such as the “randomAttribute” as shown in my sample code will remain as the orphan reference which is itself a lua table.

Now following my code, that clip is referenced by a table reference - the “list”. So my question really is, when I remove the reference to the clip from my “list” table, after performing a removeSelf() on the clip, does the clip orphan gets collected by the GC automatically? Or would the orphan clip stay in memory because I didn’t set “randomAttribute” to nil? Should I need to manually set “randomAttribute” on “graphic” and the “graphic” clip to nil ( after removeSelf() ) in order to get the graphic orphan collected by GC?

See my green comments in the code below. [import]uid: 6066 topic_id: 2162 reply_id: 6503[/import]

Hi,

After some discussion with a consortium of masters:

> So my question really is, when I remove the reference to the clip from my “list” table,
> after performing a removeSelf() on the clip, does the clip orphan gets
> collected by the GC automatically? "

No, you need to explicitly nil out the reference to the leftover orphan clip (now just a Lua table) for it to get GC’d automatically.

-- snip  
graphic:removeSelf() -- removes all rendering related resources from 'graphic'  
graphic = nil -- cleans up the leftover table, for Lua to GC automatically   
-- snip  

We will make sure our documentation is updated to reflect this. Thanks, and let me know if you need further clarification.

Tim [import]uid: 8196 topic_id: 2162 reply_id: 6546[/import]

Alright cool.

Now let me be a bit more meticulous on this topic.

So in a local function like below, do I need to nil out the local variables inside the function for those variables to be GCed?

[lua]local function doSomething()

local list1 = {1,2,3,4,5}
local randomstuff = 0
– does something here
– and here

– So question, do I need to do the things below for list1 and its contents to be GCed
while (list1[1]) do
table.remove(list1, 1)
end

randomstuff = nil
– Do I need to set randomstuff to nil for it to be GCed?
– Or the local variables only exist in the scope of this function’s execution?
end
doSomething()[/lua]

Also, I found out that calling multiple media.playEventSound() quickly at about the same time freezes up the system for about 1,2 second depending on the amount of things called. I suppose this would probably need better threading. [import]uid: 6066 topic_id: 2162 reply_id: 6604[/import]

All the locals defined in the function go away once the function exits so there is no need to “nil” out their content. The data will be GC’d.

-Tom [import]uid: 7559 topic_id: 2162 reply_id: 7068[/import]

To be a bit more precise, all locals inside of a function go away EXCEPT for tables that are returned or passed (always by reference in Lua) to some other code. Those continue to live for as long as the other code holds a reference to them…even long after the instantiating function has died. [import]uid: 6175 topic_id: 2162 reply_id: 7083[/import]

@dgadcke, My answer was in reference to the function listed but I should have given a more generic (and useful) answer. Thanks for adding the clarification.

One additional note. There are times when even locals variables defined in a function can exist after the function ends. I would suggest reading “Programming in Lua” to get a better understanding.

Thanks,
-Tom

[import]uid: 7559 topic_id: 2162 reply_id: 7084[/import]