Flash apps are growing. Maybe growing up, but also growing fat. Back in the day, I never really gave a second thought about memory usage. I mean, when you could only have a few dozen movie clips on stage at any one time without the CPU choking and gasping for breath, memory was really not on the radar.
Now, with video, bitmaps and the raw speed of AS3, how an app uses memory is a very real issue. I was working on two apps recently where the amount of memory in use by the player was actually able to crash the player. In the first one, this was not a memory leak, but the shear amount of data (bitmaps) that needed to be stored in memory. I could calculate the size and number of each bitmap and plainly see that it was using the amount of memory it should. It was just too much. We actually had to scale back the app to make it safe for public consumption.
The second one was designed by someone else, with many flaws, and John Grden and I were called in to help fix it. In this case, we were able to refactor things to free up massive amounts of memory (and also reducing CPU load by a factor of maybe 200X as well). Before we stepped in, the project was stalled because it was melting the computer before even a fraction of the features could be implemented. Now it can get back on track.
In another small app I am working on, I noticed it used more and more CPU over time. In checking into that, I also noticed a memory leak in it, where the memory use slowly increased. I have a pretty good idea what’s going on there, and hopefully the two are related so I can kill both birds with a single stone.
Just an observation. That is all.
Yep, I can definitely relate to some of these memory issues that you speak of – especially due to bitmaps. Something I have been experimenting with is loading an embedded bitmap into a static member initially and then filling Shape instances with it’s BitmapData. From what I have seen in the Flex profiler, this technique is very effective.
As far as the processor load goes, I have found that disabling mouse support for all interactive objects that do not require mouse interaction saves a ton of processor load. My case in point is a Flex application that has a ton of objects on screen. Setting ‘mouseEnabled’ and ‘mouseChildren’ to false resulted in a pretty substantial reduction in processor load while the mouse is over the application.
The other thing to watch out for that may be the cause of your slow increase in CPU over time is the garbage collector getting over worked. A common cause of this is the constant creation of objects for temporary use, in which case something like this will help you out a lot.
Hope that helps.
@Ryan Taylor: interesting. I was working on an app where performance had become a serious issue in one specific area: the gallery section. I found it strange that rolling over an item in the gallery caused huge cpu load even though the items had no complex interactivity.
Suspecting mouseEnabled to be the cause, I ran through the app setting mouseEnabled and mouseChildren to false where appropriate. It reduced the load, but not enough. In the end, all I could do was ensure that only items that were needed for display at any given time were on the display list. ie: items were added and removed from the display list as the user scrolled through the gallery.
AS3 and the AVM2 are super awesome, but there is definitely much more that a developer needs to be aware of in order to build complex applications that perform well.
I’d be interested in some details of what sort of things in AS2/AS3 cause high memory/cpu usage and leaks and how you go about tracking them down and refactoring them – I’ve always found it hard topic to really get into and a lot of the time I only get improvements through trial and error without really understanding the specifics behind why. Is there any common pitfalls, best practices and cures?
@shaun: I have noticed that setting display object’s visibility to false seems to cause a dramatic increase in performance. Do you know if there is any added benefit to removing it from the display list? I was under the impression that continuously adding/removing items from the display list would be less efficient than toggling the item’s visibility… but I don’t know that for a fact. Would be interested in learning more about the differences if anyone has some insight.
As Ryan Taylor mentioned, disabling the mouse on objects where no mouse interaction is needed can actually lead to pretty significant performance boosts when there are a large number of display objects on stage.
For one very complex application I built a while back, I crawled a display list and set mouseEnabled and mouseChildren to false on everything because CPU was spiking to 80% every time the mouse was over the application. With a single Sprite on top, I captured mouse inputs and determined which mouse-disabled display object would have been the real target. This is an extreme case where 25000+ objects could be on the display list at once, but I found it interesting that disabling the mouse brought performance back to normal. I wonder if it’s a place where Adobe could optimize a bit.
I had to know if the mouseEnabled and mouseChildren thing was true and just how great the affect actually was, so I just made and posted an experiment here:
http://natejc.com/blog/?p=83
Thanks for the tip Ryan!
@ickydime: I haven’t done any proper tests. In the app I was building, toggling the visibility didn’t seem to make enough of a difference. I’m pretty sure that adding and removing from the display list causes quite a performance hit, but it seemed to be the only thing that worked in my particular case: I had Previous/Next buttons that scrolled through large sets of items, and i did the add/remove from display list on button click – which was an acceptable place to put the performance hit. It made the tweening of the list (and rolling over of the items) much smoother.
fyi,
there is an open player bug related to this issue:
http://bugs.adobe.com/jira/browse/FP-1172
mike chambers