Is immutability and Flex a bad mix?

In my little scratch built flex game framework, I have defined a class called ThreeDPoint, that carries an x, y, and z co-ordinate set to track my in-game objects, called Actors. I also use the class to create movement vectors that stack up and are added together every frame to create a cumulative movement vector for each Actor.

I made the ThreeDPoint class an immutable to support the idea that a given position can't be altered, you can only give an Actor a new position, and also to discourage prospective client programmers (me!) from altering movement vectors in the stack, rather than allocating a new movement Vector to create the kind of movement that you want.

Unfortunately, performance on this system nosedives very quickly. Using the Flex Builder profiler, I note that I am leaking some ThreeDPo开发者_C百科int objects (with the 26 Actors I have, I should probably have about 30, but just 60 seconds of runtime brings me up to over 1000 such objects), but because the objects are so lightweight, the actual memory footprint is fairly constant.

On the other hand, the profiler shows over 250,000 ThreeDPoint objects created, cumulatively after 60 seconds of runtime. Now, being as how I'm intentionally creating and throwing away these objects, this doesn't seem at all odd to me. But the only thing that comes to mind when seeing a profile like this is that the massive number of new() and GC calls (no I'm not explicitly calling the GC) is what's killing the performance, particularly in view of the fact that when I started out and ThreeDPoint was mutable, all was well. Does this seem reasonable?

package net.emptykingdom.utils
{
    public class ThreeDPoint
    {
        public function ThreeDPoint(x:Number = 0, y:Number = 0, z:Number = 0)
        {
            this._x = x;
            this._y = y;
            this._z = z;
        }

        public function get X():Number { return _x; }
        public function get Y():Number { return _y; }
        public function get Z():Number { return _z; }

        private var _x:Number = 0;
        private var _y:Number = 0;
        private var _z:Number = 0;
    }
}

EDIT: I have found and removed the memory leak. It has resulted in a small but noticeable perf gain, although not so big as to enable a significantly larger number of Actors to be instantiated. According to the profiler, my code is still dominated by calls to the ThreeDPoint constructor. Going back to a mutable ThreeDPoint has given me back a fair bit of the performance I once enjoyed. So I guess Flex object instantiation is more expensive than other environments I've played around in. Too bad.

---

Your description is very interesting, and your suspicion -- that pre-optimizing by making the ThreeDPoint class immutable has ruined your performance -- sounds correct. You're basically substituting changing the guts of an object (mutable) with swapping the entire object out, and assuming that the gc and runtime will like that better. As you said, the instantiations and gc calls are what's gumming up the works now. So you've got only a few possibilities:

1. You're holding onto some references somewhere, or creating way more of these objects than you want, and that is killing your performance
2. By reducing the number of times the gc fires, you might be able to help your performance. I doubt this, but at least you can try it out.
3. The mutable design was better. Not in theory, but the Flash engine sees it that way.

If this problem is really interesting to you, reduce it to its core elements (mutable vs. unmutable, lots of object creations vs. mutation) and demonstrate your hunches in some test runs. Then post the results back here so we can all be smarter.

My guess: it's a clear case of trying to do favors for the Flash Engine that are not helpful.

Edit: Reading your first paragraph better I realize that you're doing it for design reasons in your program. If that is the case, unfortunately real-time programming is where OO design meets up with the harsh reality of the runtime engine.

---

You are creating 160 ThreeDPoints per Actor per second. at 30 FPS this is roughly 5 per Actor per Frame. This makes 15 calls per Actor per Frame only for reading out the coords of the ThreeDPoints. I believe, that cannot scale infinitely.

What is so wrong about Actor::moveTo(x:Number, y:Number, z:Number):void and Actor::moveBy(x:Number, y:Number, z:Number):void?

Also, for a game, I think this is a much better model for an actor (just a sketch):

package {
    public class Actor {
        private var _x:Number;
        private var _y:Number;
        private var _z:Number;
        public var xs:Number;
        public var ys:Number;
        public var zs:Number;

        public function Actor() {}
        public function get x():Number { return _x; }
        public function get y():Number { return _y; }
        public function get z():Number { return _z; }
        public function step():void {
            this.x += this.xs;
            this.y += this.ys;
            this.z += this.zs;
        }                  
    }   
}

the following interface abstracts about all influences on an Actor (forces as friction, gravity, thrust, etc).

package {
    interface IActorAffector {
        function applyTo(actor:Actor):void;
    }   
}

An Actor that just moves at constant speed only requires a call to step. that's it. You will only need to create on IActorAffector per effect that could act upon targets (source of attraction, etc.)

immutability is not so wrong, but in your case it seems to be too expensive. Also, if you're managing the ThreeDPoints well, you might wanna use an object pool to keep instantiation and GC low.

if things are performance critical, you might wanna check out Haxe. it outputs faster bytecode, allows low level memory access and allows things as read-only instance variables (compile time feature), which allows implementing immutability without having a call per field access. there're also plenty of other reasons to use Haxe, but I'll leave it up to you to find out.

---

I would say that using immutables to represent rapidly changing values in a performance sensitive app in AS3 is a bad mix, yes. AS3 isn't the fastest environment and getting it to handle 3D means squeezing performance. Asking it to create a new object for every change in the value of a primitive is probably asking for trouble.