Pooling Event objects

[chaky]

What is the real reason for not pooling flash Event objects? Is there any technical issue that is preventing Adobe implementing pooling for their internal objects like Event and TimerEvent and possibly SoundChannel?

If not for performance I am sure this can also help save a little battery on the device?

Why is Adobe so firmly against implementing pooling for those objects? Is that really that extremely dificult to implement?

[ASWC]

It's by design and it can be argue against but the reality is that Adobe won't change it since any change to those system could break existing implementations and Adobe is not interested in making AS3+. As far as Events, there are room for implementing your own pooling system, you can't stop events from being generated but you can limit their number. As for SoundChannel there's of course no solutions.

[chaky]

But honestly if you think about it, what kind of implementation would be broken if Adobe implements giving you the same object every frame instead of allocating new one? Can you think of any implementation that would break because of that?

Also when tested with Adobe Scout if I add listener to enter frame event on every frame 10kb more memory is allocated. If I do not add event listener for enter frame 10kb less is allocated on every frame. I think it is worth it.

Why is that such a big philosophy or a problem. Solution could not be more simpler. I would really like to hear if anyone knows any problem that could pop up if Adobe implements pooling of Event objects.

[ASWC]

People who work with custom events (I do) often have to override the clone method. That method is automatically called when an event propagate through the display list and creates copies of the event for each child between the dispatcher and the receiver. This is also wasteful but the point is that people do have implementations in their code of that method. Now what would happen to that method if the event system was changed especially to an automatic pooling system, I can see how internally the clone method could be adjusted to fit with a pooling system but the existing implementations and overrides in frameworks might become off or might even break forcing people to rewrite/rethink those overrides.

[ASWC]

Interestingly enough in my typescript framework (that is a clone of the flash framework) most events (especially the enterframe one) are not pooled per say but singletons so the system only creates one and only its currenttarget is modified depending on the receiver, since javascript like AS3 works on a single thread basis there's really never any need for 2 instances of one event type at the same time. Also with low level access to the sound system, all the SoundChannel are pooled and reused. So I can say that I had the same wish as you concerning AS3 but I just don't see Adobe changing anything in AS3 ever.

[chaky]

Well I understand that. Honestly the only thing that I need is just enter frame event to be pooled or maybe even simpler solution is to have ability to supply callback or something for enter frame. I mean it is really dumb to create so many objects just so that we can be notified about enter frame because we can not create our own game loops we must rely on enter frame.

But even with existing code I think this pooling can be implemented. For example when adding event listener we can supply argument if we want to receive pooled event.

[rewb0rn]

A best practice is generally to have only one central instance that listens to the ENTER_FRAME event in your application and register all other components in this central instance instead of let them having their own event listeners. Your central instance can then update all registered components whenever the ENTER_FRAME event is dispatched directly. For example we use a singleton TickDispatcher and and an interface ITickable for this that implements a tick() function.

[chaky]

Yes Starling already does that but even so if you listen ENTER_FRAME event on every frame 10kb is allocated because of that. It is still very wasteful.

[ASWC]

I never checked myself but 10k seems pretty high for just one event, on a 60fps that would be 600k every second, 36M every minute, are absolutely certain this is the memory flash request for a simple event every minute?

[ASWC]

Also I always did implement singleton or pooling of events in Java when developing for Android, it always seemed to me an absolute win on mobile until I was told by many Android developers that doing so was a waste of time because Java was very good at generating them and wiping them with very little print on memory and battery so maybe flash is also very good at that, after all events are (or should be) very small objects.

[chaky]

I made a mistake it is not 10k every frame it is 10k every second on 60FPS. But still why allocate 10K every second for no reason just to listen for enter frame. So to listen on ENTER_FRAME flash allocates 600K every minute which quite a lot just for ENTER_FRAME.

[ASWC]

I do agree this could have been better (unless there are restrictions I'm not aware of) but it seems many other technology handle it similarly and the only reason I can think of is to give the ability to the coder to keep reference of a state by keeping reference of the event which might also explain why a clone event is called automatically as to keep the original instance intact as it goes through the display list.

If it was a singleton or pooling keeping reference of the event would be pointless but also it would give you the ability to change the event values as they are being pooled and redispatched thus introducing in your code potential errors.

So I guess that's all the downfalls they are trying to avoid in a top level framework that kind of decides the design.

[chaky]

Also one more very important object to be pooled is TouchEvent. When Event.ENTER_FRAME and TouchEvent object instances are combined in a few minutes of game play you could be looking at more than 10 000 objects easily. Now nobody can tell me that pooling those objects is not worth it.

[ASWC]

It's probably worth it but it's also one case where people might want to keep reference of event objects since those are generated with very important state information. So if a pooling system were to be implemented it would have to be flexible so that people who don't want to deal with pooling can turn it off (or that can be the default) so they can do whatever they want with the event generated without any risk of mishandling them, and then people that want pooling (and deal themselves with more advanced coding) can turn it on.

Also concerning user interaction events like touchevents, those are special types since they come with user credential system that certify the event was generated by the user, when you create those event yourself they don't get those credential attached (for example you can't start printing by code, it has to start with a user generated event) so I'm not sure how those type of event would fit within a pooling system.

[chaky]

I agree with you. Now just if Adobe would implement those it would not great. But I doubt that will ever happen. It looks like AIR team is really small and they can only focus on one thing or two at the time.

I have been developing with AIR and Starling over 2 years now, almost 3. The biggest issue and performance bottleneck that I had was AS3. It was not Staging3D or graphics, that part works great. But it would be great if Adobe could spend some time in optimising av2 even more. I do not need new features with AS3.

Also one more thing that is really missed is proper multi threading, not this worker thing. I do not know if that is even possible with current state of av2 but that feature would be awesome. But again, even implementing pooling for these objects would still be awesome and a good step forward.

[Colin Holgate]

Pretty sure it would be the Flash Player team that has to do AS3 playback optimizations. No idea if that team is bigger than the AIR team.

[chaky]

Are you sure that there are separate teams, one working on Adobe AIR and other on Flash Player?

[Colin Holgate]

They do share the same product manager, but I think it's different engineers working on the player versus AIR. Can't be certain though.

[ASWC]

Well starling has its own completely independent event system and it's generating their own events, it's a design choice, if you work only in starling (no classic displayobject) then starling only catches a few classic flash events (like touch, enterframe, ect) and then use them to generate their own event from their own system. Now are you sure you are getting memory number about only the classic ones and not the starling ones? Or both? Cos of course Starling is giving them the same names.

As for workers they are not that difficult to work with once you get a hold of them and they can actually boost a lot of your app performance if you use a shared bytearray. I have a couple of classes the make working with workers very easy, I can share them if you'd like (I actually posted them somewhere on these forums for somebody else working on AIR app).