deleting variables

[carloscosta]

hi.

I was trying to understand how garbage collection works on corona, but still with no light at the end of the tunnel. my goal is if i understand it well enought i can create more robust and better “memory friendly” apps.

i tried with the basics:

local array={} for i=1, 10000 do array[i]="string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. string. " end local memUsedx local texUsedx local printMemUsage = function() memUsedx = (collectgarbage("count")) texUsedx = system.getInfo( "textureMemoryUsed" ) / 1048576 -- Reported in Bytes display.remove(memUsed) display.remove(texUsed) memUsed=nil texUsed=nil memUsed=display.newText({text=memUsedx, width=120}) memUsed.x=display.contentWidth\*.5 memUsed.y=display.contentHeight\*.5-50 memUsed:setFillColor(1,1,1) memUsed:toFront() texUsed=display.newText({text=texUsedx, width=120}) texUsed.x=display.contentWidth\*.5 texUsed.y=display.contentHeight\*.5+50 texUsed:setFillColor(1,1,1) texUsed:toFront() end if (system.getInfo("environment") == "simulator") then Runtime:addEventListener( "enterFrame", printMemUsage) end

in C when you declare an array wtih 10000 it will reserve memory for that array, even if you don’t put anything in it…its reserved to use for that array.

here in corona i don’t understand what he does. i declare it, i fill it but nothing happens…the memory is the same as before i declare and fill the array.

strange things further happens if i remove them from memory adding this code

local t local function removerArray() print ("delete array") for i=#array, 1, -1 do array[i]=nil end print (#array) array=nil timer.cancel(t ) t=nil end t=timer.performWithDelay(2000, removerArray,1)

now the memory grows like it should before i tried to remove it…and after i removed objects…the garbage collector pretty much ignored my request. I know that what i did was telling the garbage colletor that array is ready for deleting nothing more. it will clean memory at some point in the future when it needs more space. if i want to force the memory cleaning i need to do collectgarbage(“collect”). That worked fine. but why memory only grows if i tried to remove it? if i only declare and fill it why memore don’t grow? corona detects if the array is used somewhere if it’s not he doesn’t do nothing? can i conclude that lost variables that are not used anywhere will not grow 1 byte in memory? it should use space since i declare them and fill them.

regards, 

Carlos

[torbenratzlaff]

Hey Carlos,

it’s a great idea to make your code as memory efficient as possible.

But the thing is using and freeing memory does not work in LUA as it does in C.

In most cases you should not try to do the garbage collectors work (the are some occasions, like tracking memory and some special cases). LUA does a pretty good job for you. If more memory is needed, old and unused is freed.

I would not bother with garbage collection and instead read further into general LUA optimization.

Here are some links to start with:

https://docs.coronalabs.com/guide/basics/optimization/index.html

https://springrts.com/wiki/Lua_Performance

http://lua-users.org/wiki/OptimisationCodingTips

Greetings

Torben

[thomas6]

Whatever you do: always wait a minute or two for Corona to clear up memory (or until the memory has gone above a certain limit). I drove myself mad at first, trying to understand why Corona was not freeing up more memory when I wanted it to.

Turned out, my code was correct, but Corona didn’t free up memory simply because there was no need to. When I left the code to run, after a certain amount of time, sure enough garbage was collected and memory freed up.

[carloscosta]

thanks torbenratzlaff for your tips. i already use those guides in my code. always using locals, don’t use ("/"), using always “*”, passing math.* to local zbr=math, avoid using unpack, pairs and ipairs, table.insert or table.remove, etc. i’m trying to pass to a next level

good to know thomas6 that i’m not alone in this boat

[davebollinger]

you’re assigning a reference to that same constant string 10,000 times, which takes takes about 40,000 bytes (more or less, for the references themselves, plus some table overhead) – it does not create 10,000 copies of that string, so it probably isn’t causing a large enough load to the gc to be obvious.

[torbenratzlaff]

Hey Carlos,

it’s a great idea to make your code as memory efficient as possible.

But the thing is using and freeing memory does not work in LUA as it does in C.

In most cases you should not try to do the garbage collectors work (the are some occasions, like tracking memory and some special cases). LUA does a pretty good job for you. If more memory is needed, old and unused is freed.

I would not bother with garbage collection and instead read further into general LUA optimization.

Here are some links to start with:

https://docs.coronalabs.com/guide/basics/optimization/index.html

https://springrts.com/wiki/Lua_Performance

http://lua-users.org/wiki/OptimisationCodingTips

Greetings

Torben

[thomas6]

Whatever you do: always wait a minute or two for Corona to clear up memory (or until the memory has gone above a certain limit). I drove myself mad at first, trying to understand why Corona was not freeing up more memory when I wanted it to.

Turned out, my code was correct, but Corona didn’t free up memory simply because there was no need to. When I left the code to run, after a certain amount of time, sure enough garbage was collected and memory freed up.

[carloscosta]

thanks torbenratzlaff for your tips. i already use those guides in my code. always using locals, don’t use ("/"), using always “*”, passing math.* to local zbr=math, avoid using unpack, pairs and ipairs, table.insert or table.remove, etc. i’m trying to pass to a next level

good to know thomas6 that i’m not alone in this boat

[davebollinger]

you’re assigning a reference to that same constant string 10,000 times, which takes takes about 40,000 bytes (more or less, for the references themselves, plus some table overhead) – it does not create 10,000 copies of that string, so it probably isn’t causing a large enough load to the gc to be obvious.