Tween* constantly creates Event instances

[aldipower]

Hi,

 

I have just run the memory profiler, that is included in FDT 4.2, on my AS3 application.

After I've created a TweenLite (or TweenMax) instance on a test-Shape I noticed that a lot of Event-instances get constantly created and droped immediately,

even if the tween finished.

About 30 instances per second, maybe it has to do with my framerate of 30fps.

So the cumulative instances count increases constantly.

 

The problems is that this costs a little bit of performance by creating and garbage collect these instances every time, for nothing, no tween is actually running.

 

It would be very nice, if the tweeners are in true idle mode or better completly deleted from memory, after they was used.

 

Anyway thanx for the great job!

 

AldiPower

[GreenSock]

Sounds like you're talking about ENTER_FRAME events that Flash creates each time it renders a frame. This isn't a performance hog and I explain why it's necessary here:

viewtopic.php?f=1&t=2674&p=10137#p10137

[aldipower]

Yeah, every frame an Event instance gets created by the ENTER_FRAME event and immediately deleted by the garbarage collector.

 

Your explanation is a good design for TweenLight in order to reduce Kb and the aspect that TweenLight is possibly most used in browser applications that get closed after usage.

But I can't totally agree with your 4 points in relation to TweenMax.

I'm using TweenMax in a touchtable application that never gets closed (in ideal case).

So after a week I have 18144000 cumulative instances at 30fps.

Ok it not really produces a lot of load, but it does produce load, while my app is doing nothing.

I want that my application does nothing while it's doing nothing. Clean behaviour, reducing possible side effects in large applications.

And I guess that instanciate an Event and call the listener method every frame costs much more load than a conditional statement that only gets evaluated while tweening.

 

So it's only my humble point of view.

 

Thank you very much for listening.

[GreenSock]

I guess we'll have to agree to disagree. The fact is that the Flash player continues to render frames at whatever fps you set regardless of whether or not TweenLite asks Flash to notify it. So after a week, it had to render 18144000 frames in your example. The rendering happens either way. The only difference here is that it passes an Event instance to a method in TweenLite. If one method call and one event instance each render bogs down your application, there must be very significant problems elsewhere. And it sounds like you're putting way too much weight and focus on cumulative instance totals - remember that event objects are swept away by garbage collection very quickly and they take up very little memory.

 

More importantly, you must consider where optimizations make the most sense. If I implemented your suggestion, it would require extra conditional logic EVERY time a tween starts and ends plus a method call each time a tween starts or ends when no others are running. The time you NEED the most optimization in the engine is when it's under heavy loads which is exactly when your suggestion would be the MOST costly in terms of performance. Imagine, for example, creating 1000 tweens every second (I've actually had an app that created 10,000 per second by the way). Your suggestion would cost an additional 2000 conditional statement evaluations each second and at least 2 more method calls depending on the duration of the tweens. Not to mention the extra kb. I'd much rather have the EXTREMELY small overhead of an event object getting created on each frame (and disposed almost immediately) while the application is idle rather than adding kb and slowing things down when the engine is under the most pressure to perform well. See what I mean?

 

And don't forget the point I made about the ENTER_FRAME notifications being critical for synchronizing the timing of everything in the engine. This is actually the most important factor of all.

[aldipower]

Thanx for your detailed answer.

Maybe you're right with agree to disagree.

I can understand and accept your points and decissions. Good ones.

Why I am putting weight on the cumulative instance totals is to show that TweenLite is doing somethig while it's not used.

If this is neccessary for the timing then it's all right of course, but I have no clue.

Maybe it's possible to implement a cleanup function that must be called manually in Tween_Max_, to get the initial state of the tweener?

Before the first run of the tweener nothing happens with the cumulative instances, so it should be possible to cleanup all things by an additional function, that don't affects the tweening process function with conditional statements.

What do you think?

[Carl]

aldipower,

 

if you are still concerned that ENTER_FRAME events naturally being fired by flash are having a negative impact on the performance of your app you can chose to code you app in a way that lowers the frame rate when it is inactive / idle:

 

http://www.gotoandlearn.com/play.php?id=112

 

Jack, thanks for the clear explanation on all this. From my experience too, an ENTER_FRAME listener that does virtually nothing isn't going to stress an application.

[X10]

This has been an interesting thread to read through, even if some of it was way over my head.

Carl, thanks for the link, very interesting stuff, I didn't know you could change the FPS of the SWF like that. I also understand that Flash 9 and up does a similar thing automatically with regards to resources when the browser is minimised or you go to a different tab.

[Carl]

no problem X10. I will admit that the thought of flash always doing something at 30fps regardless of how small does make my brain think it is a lot of work. in reality though any computer at idle is probably running dozens of processes and performing 1000s of calculations constantly. its hard to fathom how 3d games are rendering thousands of polygons a second and so forth. In the olden days enterframe events were considered sort of taboo if not dangerous. That had a lot to do with the capabilities of the flash player... and still does to some extent. Things are much better.

 

I also understand your concern when dealing with a persistant app that may be running for days and months. Flash has a reputation for memory leaks and such. Flash has come a long way though and is powering multi-story high displays in times square nyc around the clock.

http://blogs.adobe.com/lifeasanse/2007/ ... lboar.html

 

I've also learned to accept that Jack doesn't sling any nonsense, even if I don't immediately understand it:) GreenSock has been optimized to the nth degree and battle tested excessively. I'm quite sure you are going to be just fine.