Question

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 ThreeDPoint 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.

Answer 1

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.