The forums have permanently moved to forum.kirupa.com. 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

Hybrid View

  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
    Quote Originally Posted by Dazzer View Post
    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.
    I think what Rez is trying to achieve is a sort of "best practices for helping the GC / AVM", rather than explicit memory management of moving actual bits and bytes about

    Things like using weak references for listeners and so forth.

    Which raises a question I've wanted to ask - Rez, with weak listeners... when the object they're sending events to is de-referenced and marked for deletion, does the listener die as well? Or do you need to remove both the listener and the listenee?

  4. #4
    Quote Originally Posted by dthought View Post
    Rez, with weak listeners... when the object they're sending events to is de-referenced and marked for deletion, does the listener die as well? Or do you need to remove both the listener and the listenee?
    When an event listener is added to an object, a reference is made between the listener and the dispatcher. If the reference is weak, the reference count on the dispatcher stays the same; if the reference is strong, the reference count goes up by 1. The garbage collector will use the reference count of an object to determine when to delete it, and because the listener's reference count doesn't change due to addEventListener(), it will not be affected by what happens to the dispatcher. How's that?

    EDIT: Short answer- the listener won't "die" simply because the dispatcher did.

  5. #5
    Quote Originally Posted by dthought View Post
    I think what Rez is trying to achieve is a sort of "best practices for helping the GC / AVM", rather than explicit memory management of moving actual bits and bytes about

    Things like using weak references for listeners and so forth.
    I know that.

    Funnily though I've never had any trouble with the GC. Maybe call me lucky, or maybe my programs are never complex enough. Which begs the question... just how many people out there are going to push the limits of what AVM2 can do?

    While I can appreciate what Rez is trying to do, I feel it might be just "seeing a storm when it is barely a cloud". Not to mention a (more than) healthy dose of self-promotion makes me a tad skeptical.

    But hey, thumbs up to rez for the effort.

  6. #6
    Quote Originally Posted by Dazzer View Post
    I know that.

    Funnily though I've never had any trouble with the GC. Maybe call me lucky, or maybe my programs are never complex enough. Which begs the question... just how many people out there are going to push the limits of what AVM2 can do?
    .
    Once you run into an issue like this, you will not find yourself going to a forum like this one, to solve your problem. As the projects you are working are simply too complex to allow insight into the whole problem by use of a forum.

    People who run into these problems are rarely found on forums, posting said problems. They are the kind of people that usually seem to do nothing but solve other people's issues.
    Personal HemiSphere
    It's mine (Opel GT 72 1900)

  7. #7
    Quote Originally Posted by Dazzer View Post
    Funnily though I've never had any trouble with the GC. Maybe call me lucky, or maybe my programs are never complex enough. Which begs the question... just how many people out there are going to push the limits of what AVM2 can do?

    While I can appreciate what Rez is trying to do, I feel it might be just "seeing a storm when it is barely a cloud". Not to mention a (more than) healthy dose of self-promotion makes me a tad skeptical.
    You're right, and I'm trying to keep the self-promoting at a minimum. But how many AS3 profilers are out there, anyhow?

    I don't doubt that you've never had memory leaks, Dazzer, and if your Flash projects are small, you probably won't benefit from this thread. Especially if you have a background in C. But folks migrating from AS2 will often make leaks by mistake. A bigger issue, though, is that most migrators who first hear about memory leaks will try graphing their System.totalMemory and misinterpret the graph as an indication that their memory is leaking. The diagnosis posts are meant to clarify the difference between total memory and active memory, and what it takes to discover a leak. After I wrap up the memory leak spiel, maybe the next topics will have more significance to you, though considering what you've already said about your programming habits, I doubt it.
    Last edited by Rezmason; May 28th, 2007 at 11:00 AM.

  8. #8
    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.

  9. #9

    Overview

    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.

  10. #10

    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.

    Code:
    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 {
    			trace(System.totalMemory);
    		}
    
    		private function spit2():void {
    			n = System.totalMemory;
    			if (n != lastN)
    				trace(n);
    			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.

  11. #11
    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?

  12. #12
    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.

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

    Can you replicate?

  14. #14
    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?

  15. #15
    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?

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 kirupa.com Meet the Moderators Advertise

 Link to Us

 Credits

Copyright 1999 - 2012