Runtime listeners - get the name of the event listener function / table assigned?

Solar2D Lua Language
#1

Hi;

I have a function that checks memory usage every 20 seconds or so in an app.

Here’s the problem: (I know it can be caused by many different things - I want to rule out duplicate runtime listeners)

The memory usage is constantly increasing. Not really a big deal - however, after playing for about 2 minutes or more it starts to slow the app down.

Is there a way to get the name of the  function assigned to the listener - or some identifier other than the “table name” of the listener which looks like Alien language to me?

I am using the code example from this post:

http://forums.coronalabs.com/topic/14982-how-to-check-if-listener-already-exists/

I’m using the following code:

if Runtime._functionListeners.enterFrame then --checking for runtime event listener

for _,func in pairs(Runtime._functionListeners.enterFrame) do

print("RuntimeListeners : ", func) – Is there a way to print out the result in something I can understand? or the name of the function assigned to the runtime listener?

end

end

I want to eliminate the possibility of duplicate listeners in the runtime.

Any help would be greatly appreciated.

Cheers!

#2

PS>

This is the check memory function (run every 20 seconds)

function checkMemory()

   collectgarbage( “collect” )

   local memUsage_str = string.format( “MEMORY USAGE = %.3f KB”, collectgarbage( “count” ) )

   print( memUsage_str, "TEXTURE MEMORY USAGE = "…(system.getInfo(“textureMemoryUsed”) / (1024 * 1024) ) )

end

#3

IMO checking the status of an RTEL by checking Corona’s internal structures is a dodgy idea. They may change - published APIs change, unpublished ones are more prone to it.

The simplest way to track the addition and removal of RTEL is to have a variable which counts them (or tracks their connection). Wrap the Runtime:addEventListener/remove in a function with that variable adjustment, then you can track what  you are doing.

#4

Nice. That makes it much easier.

I guess wanting to know which RTEL is running/listening stems for the day I had yesterday trying to find the cause of the lag/problem…

Still haven’t found it, and the memory increasing arbitrarily (for example when the app is just sitting - no interaction) - concerns me for the performance of the app. Maybe I need to look more into garbage collection. Just trying to rule out any potential causes one at a time - fun!

Cheers!

#5

It’s evil. 

One thing that I do which helps is when freeing stuff up, make sure *everything* is freed - if you have a table or class representing some object in your code, deliberately nil everything - e.g.

t.x = nil t.y = nil t.someReference = nil t.score = nil t.object:removeSelf() t.object = nil

sort of thing - now obviously you could just do 

t = {}

and do the same thing, but what I’ve found is doing this makes you think about what you are doing when you are tidying up, what references there are, are there any circular references or similar. You can put code in like

for k,v in pairs(t) do print(k,v) end

which shows everything you haven’t deliberately nulled out.

Windows used to have the same problem, whenever  you wanted a chunk of memory you had to GlobalAlloc() it then GlobalLock() it to use it, and GlobalUnlock() and GlobalFree() to undo it. It was very easy to forget to unlock, or free, and then memory just went nuts.

Encapsulating construction/destruction of the parts of your code helps with these sorts of problems.

#6

Yes it is evil. :slight_smile:

I usually null stuff out by using the t = {} method but perhaps I will start nulling out each entry one by one, I question whether  all parts are actually nil, I trust that they are and usually then move on to the next bit of code I was working on.

Cheers!

#7

PS>

This is the check memory function (run every 20 seconds)

function checkMemory()

   collectgarbage( “collect” )

   local memUsage_str = string.format( “MEMORY USAGE = %.3f KB”, collectgarbage( “count” ) )

   print( memUsage_str, "TEXTURE MEMORY USAGE = "…(system.getInfo(“textureMemoryUsed”) / (1024 * 1024) ) )

end

#8

IMO checking the status of an RTEL by checking Corona’s internal structures is a dodgy idea. They may change - published APIs change, unpublished ones are more prone to it.

The simplest way to track the addition and removal of RTEL is to have a variable which counts them (or tracks their connection). Wrap the Runtime:addEventListener/remove in a function with that variable adjustment, then you can track what  you are doing.

#9

Nice. That makes it much easier.

I guess wanting to know which RTEL is running/listening stems for the day I had yesterday trying to find the cause of the lag/problem…

Still haven’t found it, and the memory increasing arbitrarily (for example when the app is just sitting - no interaction) - concerns me for the performance of the app. Maybe I need to look more into garbage collection. Just trying to rule out any potential causes one at a time - fun!

Cheers!

#10

It’s evil. 

One thing that I do which helps is when freeing stuff up, make sure *everything* is freed - if you have a table or class representing some object in your code, deliberately nil everything - e.g.

t.x = nil t.y = nil t.someReference = nil t.score = nil t.object:removeSelf() t.object = nil

sort of thing - now obviously you could just do 

t = {}

and do the same thing, but what I’ve found is doing this makes you think about what you are doing when you are tidying up, what references there are, are there any circular references or similar. You can put code in like

for k,v in pairs(t) do print(k,v) end

which shows everything you haven’t deliberately nulled out.

Windows used to have the same problem, whenever  you wanted a chunk of memory you had to GlobalAlloc() it then GlobalLock() it to use it, and GlobalUnlock() and GlobalFree() to undo it. It was very easy to forget to unlock, or free, and then memory just went nuts.

Encapsulating construction/destruction of the parts of your code helps with these sorts of problems.

#11

Yes it is evil. :slight_smile:

I usually null stuff out by using the t = {} method but perhaps I will start nulling out each entry one by one, I question whether  all parts are actually nil, I trust that they are and usually then move on to the next bit of code I was working on.

Cheers!