The forums have permanently moved to This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.

Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: AS3 Memory Management Tips

  1. #1

    AS3 Memory Management Tips

    Hello. This thread is intended to make the memory management concepts I've talked about before on this forum a little easier to understand and put to use. I hope this keeps people from having to sift through the earlier threads, which contain lots of dead ends and pointless information. Also, by packing this information together, people whose projects are too advanced for me to understand can consult this single reference rather than asking me directly for help.

    If anyone else has questions or strategies of their own, feel free to post them. This a forum thread, after all. I doubt that this thread will grow large enough to need an index, like some other threads , but I'll try to keep things organized. I'm going to begin with the very basics and work up to more complicated things.

    And maybe I'll include sample code and some SWFs! How does that sound?

  2. #2
    Well, that is a very very "poor" definition there, I feel.

    There isn't anyway for you to perform memory management like you'd do in C, in AS3. That's what the AVM is for. (Or in Java's case, the JVM). It already has its default implementation of memory management. The best you could do is simply take note of all the quirky personality of the AVM, and GC.

    Right? lol

  3. #3
    I mostly agree with you, but unless the AVM can prevent memory leaks (and it certainly cannot), there is still some sort of memory management that Flash developers have to do themselves. They need to properly relinquish their unused objects to the GC, which is easy to do if you know what you're doing. If you don't, that's primarily what this thread is for.

    Also, I plan to discuss ways to optimize your garbage for the GC. Actionscript's virtual machine will take longer to remove garbage of a certain form, and if you properly "format" your garbage before relinquishing it, theoretically you can improve your app's performance. I'm still researching this, but for game designers, who are most affected by the GC, reducing overhead is a high priority.

    So no, I don't think "memory management" is at all a "poor" definition.

  4. #4


    With the advent of AS3, ActionScript has become a language to take seriously. Flash solutions are expected to do unprecedented things as applications, faster than they ever have before, but are also expected to run continuously for hours as elements of a website, without any complications. If Flash content only belonged to one of these camps, memory management wouldn't be an issue.

    However, not everyone needs to concern themselves with every facet of this issue. If you're working on something simple, your knowledge on this matter can be kept basic. There are three goals of Flash memory management:

    1. To keep your code from crashing the browser/player/app
    2. To keep your memory usage low
    3. To reduce the burden on the built-in memory management system

    -and most of us should only worry about the first. So don't sweat the small stuff if you don't have to.

  5. #5

    Diagnosing: How do I know if my program has an issue?

    Most AS3 beginners have programmed something and then heard about memory leaks. So first I'm going to cover ways to detect and fix leaks in preexisting code, and then talk about preventative measures to take when starting to program.

    So how do you know if your program has an issue? The clearest way to tell is if it crashes, but that's very impractical. Fortunately, in AS3 we have an object called System whose properties tell us about the conditions under which Flash is running. System.totalMemory, for instance, is the amount of computer memory being used by the Flash Player instance that's running your program. Different platforms determine the value of System.totalMemory in different ways, so I suggest you only run one Flash player instance at a time when measuring its value.

    package {
    	import flash.utils.Timer;
    	import flash.system.System;
    	public class SpitMem {
    		var t:Timer = new Timer(0);
    		var n:int, lastN:int;
    		public function SpitMem():void {
    			t.addEventListener("timer", spit2, false, 0, true);
    		private function spit1():void {
    		private function spit2():void {
    			n = System.totalMemory;
    			if (n != lastN)
    			lastN = n;
    If you create an instance of the SpitMem class above and run your code, you can observe the fluctuations in your program's memory usage in the Output window. This is a lot of information, though, and in this format it cannot give you a clear picture of how your program is using its memory.

    (Notice the difference above between spit1() and spit2(). spit2() won't output the System.totalMemory if it hasn't changed. Later I'll show how similar logic can turn our data into something more useful.)

    If you make a graph of your data in a spreadsheet program, you'll notice that it always seems to be increasing. That doesn't mean that you have a memory leak. Flash's built-in memory management allows certain types of data to sit around until there is an appropriate time to get rid of it. This is called garbage collection, and for most Flash projects, it will cause your memory to accumulate and then dip down. This is called a sawtooth graph, and it's completely normal.

    Click here to see a memory usage simulator created by Grant Skinner for Adobe. As you can see, the "garbage" memory accumulates until the totalMemory reaches a certain capacity, and then the garbage collector is run, causing the steady increase and sudden dips in the graph. (The actual graph that your code generates may differ somewhat from this graph, but follows the same principles.)

    Not all memory must go through this garbagey phase. Primitive objects, such as Booleans, Strings, Arrays, and Numbers are deleted the minute they are no longer needed. Also, some of the memory used by Flash is simply not managed by the garbage collector.

    Regardless, simply tracing System.totalMemory will not help you determine whether you have a memory leak. Leaks are caused by memory that should be garbage, but for some reason is sticking around. We'll see some reasons why later. The point is, in order to spot a leak, you need to be able to disregard the garbage and observe the active memory that your program is using. That is what I programmed ActiveGraph to do; it will only spit out System.totalMemory when there's been a dip in the graph, when there is supposedly no garbage. I won't post ActiveGraph's source code here, but I recommend that you read it and see what it's doing.

    By default, ActiveGraph counteracts not one, but two sawtooth patterns in the changing value of System.totalMemory

    (SWF in a minute.)
    Last edited by Rezmason; November 3rd, 2007 at 02:00 PM.

  6. #6
    Hi Rezmason, just to check with you... I am using 1.3 of the ActiveGraph... if I put only the graph in an empty fla and make it loop between frame 3 and 4 which has no AS in them... the memory will slowly creep one 1 byte at a time.. is this a leak in AG? or its a flaw in Flash?

  7. #7
    Hrm, I'm trying to replicate what you did... Check to make sure you're not creating a new graph each time you loop.

    BTW, it's not creeping at 1 byte at a time but at 4K at a time, or a page. AG measures memory in pages, 'cause that's the smallest bite Flash seems to take out of your memory at a time.

  8. #8
    Nope it is not a new graph... I made frame 3 and 4 as empty keyframe and loop between them...

    Can you replicate?

  9. #9
    Let me get this straight: you've got nothing in keyframe 1 or keyframe 2, and you've got code in keyframe 4 that goes back to keyframe 3... and where are you putting the graph? Is it in an external class somewhere?

  10. #10
    Frame 1 is the import and declare of Activegraph and addChild of that var.
    Frame 2 is an empty key frame
    Frame 3 is an empty key frame
    Frame 4 is a gotoAndPlay(3)

    Thats all. Am I doing this right?

  11. #11
    The only creeping I can see is if you set the degree of the ActiveGraph to 0. In that case, the creeping is just garbage accumulating. At degree 2 (the default setting), I'm not getting anything.

    How about you attach the .fla, eudora?

  12. #12

    ActiveGraph and the sawtooth graph (Diagnosis cont'd)

    Here's a rudimentary Flash memory simulator that shows what ActiveGraph attempts to do. The memory actually in use, the active memory, is represented in tan on the bottom. On top of it is a sawtooth graph in red, and on top of that is another sawtooth graph in burgundy. This is the graph you'll get from tracing System.totalMemory, only you won't be able to tell the garbage apart from the active stuff.

    The pink and cream arrows mark points recorded by ActiveGraph at degree 1. The cream ones also mark points recorded at degree 2. The degree 1 points "overlook" the burgundy sawteeth, and the degree 2 points "overlook" the red sawteeth– though the red ones will sometimes throw off ActiveGraph's accuracy, since they do not cut off instantly like the burgundy ones. The whole graph is regulated by the OS (the grey bars on top), and if the active memory ever goes higher than this ceiling, the program will "crash". (If this happens in the simulation, just reload the page and the fun will recommence.)

    Gist: The tan graph at the bottom is the information you want. By graphing just the points under the cream markers, ActiveGraph gives you an okay estimate.

    Note that the garbage in the simulator above increases steadily. Often this is not the case: the frequency of garbage production depends on the structure of your code. The simulated garbage is just a generalization.

    ActiveGraph is by no means accurate, even at this stage. But it fulfills its purpose, which is to show you whether you have a memory leak. If you run ActiveGraph for an hour in your program, and the data it gives you shows an upward trend, you can suspect a memory leak and then take action. Expect better versions of ActiveGraph, and a better AS3 "profiling system" (as they're otherwise known) from Adobe in recent months.

    So without resorting to ActiveGraph, finding out whether you have a leak can be a real pain. With that over with, next let's see how we can stop a leak in our code.
    Last edited by Rezmason; May 2nd, 2008 at 01:01 PM. Reason: switched colors to Cherry Cheesecake theme from

  13. #13
    Yea it was on 0. That explains the creeping...
    If that is the case, is degree 2 good enough to check on the memory usage of a flash game? I am doing a similar gotoAndPlay previous frame to do the Update->Draw process of my game...

    Quote Originally Posted by Rezmason View Post
    The only creeping I can see is if you set the degree of the ActiveGraph to 0. In that case, the creeping is just garbage accumulating. At degree 2 (the default setting), I'm not getting anything.

    How about you attach the .fla, eudora?

  14. #14
    Quote Originally Posted by Rezmason View Post
    So without resorting to ActiveGraph, finding out whether you have a leak can be a real pain. With that over with, next let's see how we can stop a leak in our code.
    Just to check on this issue... if you are loading external swf... and that external swf has memory leak, it will be translated in my main swf as well right?

  15. #15
    Sorry, I've been without Internet for a short while.

    Degree 2 will let ActiveGraph "overlook" second-order garbage– stuff that will accumulate under first-order garbage, until the GC cleans it up as well. Second-order garbage usually consists of the data you put in a Timeline. If you're not using Timelines in your project, you can switch to Degree 1.

    If your program makes no garbage and you want to show it off to friends, use Degree 0.

    As for loading external SWFs, their memory use will be reflected in the loader's memory use.

Page 1 of 3 123 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Home About Meet the Moderators Advertise

 Link to Us


Copyright 1999 - 2012