Been increasingly using dispatch events to move between parent and required modules. At any one time we’ve got around 6 runtime event listeners doing their thing. How much are these kinds of listeners a draw on memory and is there an ideal number to stay under?
Hi @kilopop,
What you have (6) doesn’t seem excessive. I can’t say that there’s a “limit” you should stay under… just follow best coding practices, optimize wherever you can, and test on various devices.
Take care,
Brent
I’ve tested this purely for curiosity sake and last I saw, you can have thousands or even 10’s of thousands before you see any issue. The real question is, “how much work is done in the listener”. More work, equals more waste.
The mechanism for calling Runtime events is pretty light.
Having said that, fewer of everything is better. Like Brent said, follow best coding practices and you should be fine.
I can confirm: I had a particle system with 5000 bullets, each an instance with it’s own enterFrame listener. Ran perfectly on an iPhone 3 even.
And conversely, yes, a single enterFrame listener with poor code or too heavy operation can potentially be worse!
Good stuff, thanks for the replies.
Listeners do different things. A listener that just sits there waiting for an event to be dispatched is hardly any CPU. The cost really is the fact that the listeners are tracked in a table and Lua has to manage that table. I’m not sure if it’s using a numerical index or not (I suspect that’s the case), so it may have to loop over a big table to find your event info which can take some time. It’s not a big performance hit with today’s CPU’s to loop over 5000 entries looking for a match (since we are dealing with 10’s of millions instructions per second).
But things like enterFrame listeners run every frame (up to 60 times per second) and if you have a bunch of those doing a lot of work, then you can start impacting performance.
Rob
Hi @kilopop,
What you have (6) doesn’t seem excessive. I can’t say that there’s a “limit” you should stay under… just follow best coding practices, optimize wherever you can, and test on various devices.
Take care,
Brent
I’ve tested this purely for curiosity sake and last I saw, you can have thousands or even 10’s of thousands before you see any issue. The real question is, “how much work is done in the listener”. More work, equals more waste.
The mechanism for calling Runtime events is pretty light.
Having said that, fewer of everything is better. Like Brent said, follow best coding practices and you should be fine.
I can confirm: I had a particle system with 5000 bullets, each an instance with it’s own enterFrame listener. Ran perfectly on an iPhone 3 even.
And conversely, yes, a single enterFrame listener with poor code or too heavy operation can potentially be worse!
Good stuff, thanks for the replies.
Listeners do different things. A listener that just sits there waiting for an event to be dispatched is hardly any CPU. The cost really is the fact that the listeners are tracked in a table and Lua has to manage that table. I’m not sure if it’s using a numerical index or not (I suspect that’s the case), so it may have to loop over a big table to find your event info which can take some time. It’s not a big performance hit with today’s CPU’s to loop over 5000 entries looking for a match (since we are dealing with 10’s of millions instructions per second).
But things like enterFrame listeners run every frame (up to 60 times per second) and if you have a bunch of those doing a lot of work, then you can start impacting performance.
Rob