Question regarding lua memory...

[d.mach]

My memory monitor is showing me a small but constant growing number of used lua memory when accessing local functions and variables more than once. Is this normal? With texture memory I know how to handle it, because I can watch the objects… but how can this be done with the lua memory? It’s not much, but it constantly adds with each action I’m doing (for example) inside a game level… push a button, building something and so on. When the level is starting the memory used is about 0.48 MB, but with each action I do inside this level it is growing, so I get after a view minutes up to 2 MB. I think it’s nothing to worry about, but maybe there is a “Way how to handle” this kind of memory usage?

Thank you for your help!

Daniela

[torbenratzlaff]

As I know this is absolutly normal. If you call functions or aks for variables the needed memory grows.

But that should only happen once.

So if you press a button which has a listener, the memory goes up. But if you press it again the memory should stay the same in most cases. Only if it goes up again and again you’ve got a problem. (memory leaks)

[d.mach]

Thank you for your fast answer. I just noticed something else: I have some growing tables in the game and I think they are the main reason for the growing lua memory.

Is there a “Best way” to handle tables with stored information, so they can be “made smaller” while the game is running? For example:

I’m storing references to objects like:

myhero=newSprite…

myenemy1=newImage…

myenemy2=nemImage…

myenemy3=newImage…

tableobj[1]=myhero

tableobj[2]=myenemy1

tableobj[3]=myenemy2

tableobj[4]=myenemy3

now let’s say I destroy two enemies while playing… let’s take enemy1 and 2…

and I do:

myenemy1:removeSelf()

myenemy1=nil

myenemy2:removeSelf()

myenemy2=nil

Now what should I do with the table? Do I have to set nil to the index where the enemy images were before? Like this:

tableobj[2]=nil

tableobj[3]=nil

Is this what is meant with “the memory is only freed, when there are no other existing references to objects”? Will the lua memory decrease also, when I set the indexes in the table nil and run a garbage collection?

Any help welcome

Daniela

[torbenratzlaff]

Yes you are right at this point.

You have to nil the reference in the table as well.

The problem is most times you don’t know the table index of an object.

And after you niled it there’s nearly no way to get it’s index.

So the order in which you nil is important.

local indexing = table.indexOf   local obj\_table = {}   local object = display.newImage(...) obj\_table[#obj\_table+1] = object     display.remove(object) obj\_table[indexing(obj\_table, object)] = nil object = nil

There might be a better way (better performance) but that’s how I do it. And it worked out quite well for me.

[roaminggamer]

@d.mach,

Consider too that you can use anything as an index and in the case of objects, you can just use their ids which makes for easy lookup and clearing.

Here is a random example demonstrating the idea:

local myObjects = {} local function onTouch( self, event )    if( event.phase == "ended" ) then       timer.performWithDelay( 10,          function()             myObjects[self] = nil -- Easy removal from the list             self:removeSelf()          end )    end end local function makeCircles()    local tmp = display.newCircle( 100, 100, 10 )    myObjects[tmp] = tmp -- Easy addition to the list    tmp.touch = onTouch    tmp:addEventListner( "touch", tmp )    local tmp = display.newCircle( 200, 100, 10 )    myObjects[tmp] = tmp -- Easy addition to the list    tmp.touch = onTouch    tmp:addEventListner( "touch", tmp ) end makeCircles() -- Easy way to iterate over list for k,v in pairs( myObjects ) do print(k,v) -- key and value are same in this case end -- Now, touching these circles removes them from the myObjects -- list and destroys them  

[torbenratzlaff]

Wow, that is a great idea using the objects id as an index. Never thought of that.

The only I ask my self is the performance, cause in pairs is not the fastest operator as far as I know. (don’t no how fast table.indexOf is)

So it might depend on the situation which one is better. If you have to loop through a list very often (like in enter frame) the in pairs solution might be slower. But if you create and remove many objects it might be faster.

Have to do a test when I’ve got some time.

[torbenratzlaff]

As I know this is absolutly normal. If you call functions or aks for variables the needed memory grows.

But that should only happen once.

So if you press a button which has a listener, the memory goes up. But if you press it again the memory should stay the same in most cases. Only if it goes up again and again you’ve got a problem. (memory leaks)

[d.mach]

Thank you for your fast answer. I just noticed something else: I have some growing tables in the game and I think they are the main reason for the growing lua memory.

Is there a “Best way” to handle tables with stored information, so they can be “made smaller” while the game is running? For example:

I’m storing references to objects like:

myhero=newSprite…

myenemy1=newImage…

myenemy2=nemImage…

myenemy3=newImage…

tableobj[1]=myhero

tableobj[2]=myenemy1

tableobj[3]=myenemy2

tableobj[4]=myenemy3

now let’s say I destroy two enemies while playing… let’s take enemy1 and 2…

and I do:

myenemy1:removeSelf()

myenemy1=nil

myenemy2:removeSelf()

myenemy2=nil

Now what should I do with the table? Do I have to set nil to the index where the enemy images were before? Like this:

tableobj[2]=nil

tableobj[3]=nil

Is this what is meant with “the memory is only freed, when there are no other existing references to objects”? Will the lua memory decrease also, when I set the indexes in the table nil and run a garbage collection?

Any help welcome

Daniela

[torbenratzlaff]

Yes you are right at this point.

You have to nil the reference in the table as well.

The problem is most times you don’t know the table index of an object.

And after you niled it there’s nearly no way to get it’s index.

So the order in which you nil is important.

local indexing = table.indexOf   local obj\_table = {}   local object = display.newImage(...) obj\_table[#obj\_table+1] = object     display.remove(object) obj\_table[indexing(obj\_table, object)] = nil object = nil

There might be a better way (better performance) but that’s how I do it. And it worked out quite well for me.

[roaminggamer]

@d.mach,

Consider too that you can use anything as an index and in the case of objects, you can just use their ids which makes for easy lookup and clearing.

Here is a random example demonstrating the idea:

local myObjects = {} local function onTouch( self, event )    if( event.phase == "ended" ) then       timer.performWithDelay( 10,          function()             myObjects[self] = nil -- Easy removal from the list             self:removeSelf()          end )    end end local function makeCircles()    local tmp = display.newCircle( 100, 100, 10 )    myObjects[tmp] = tmp -- Easy addition to the list    tmp.touch = onTouch    tmp:addEventListner( "touch", tmp )    local tmp = display.newCircle( 200, 100, 10 )    myObjects[tmp] = tmp -- Easy addition to the list    tmp.touch = onTouch    tmp:addEventListner( "touch", tmp ) end makeCircles() -- Easy way to iterate over list for k,v in pairs( myObjects ) do print(k,v) -- key and value are same in this case end -- Now, touching these circles removes them from the myObjects -- list and destroys them  

[torbenratzlaff]

Wow, that is a great idea using the objects id as an index. Never thought of that.

The only I ask my self is the performance, cause in pairs is not the fastest operator as far as I know. (don’t no how fast table.indexOf is)

So it might depend on the situation which one is better. If you have to loop through a list very often (like in enter frame) the in pairs solution might be slower. But if you create and remove many objects it might be faster.

Have to do a test when I’ve got some time.