Getters and setters are indeed a very nice feature of AS3. They eliminate a lot of typing (.x versus .getX()) shaves off five characters and removes the need to hit the shift key for X) and make getting and setting values much more natural by disguising the fact that you’re actually calling a function. The downsides include the difficulty (impossibility?) of getting a Function variable for them and lower performance. This article is about that performance hit. EDIT: added a plain getter test)

Getters and setters appear frequently in the Flash API. Unless you’ve carefully inspected the Flash API documentation, you probably wouldn’t even know that such common “properties” as x and y of DisplayObject are implemented by getters and setters. Take a look at the documentation of DisplayObject and notice that x and y are listed under “Public Properties”, not “Public Methods”. Then go to the x “property” and notice that only under “Implementation” does it actually reveal the getter and setter. What kind of performance hit do you get due to Adobe’s decision to make such commonly-accessed properties getters and setters? Consider this test app:

package
{
    import flash.display.*;
    import flash.geom.*;
    import flash.text.*;
    import flash.utils.*;
 
    /**
    *   An app to test the performance of getters against public variables
    *   @author Jackson Dunstan
    */ 
    public class GetterTest extends Sprite
    {
        public function GetterTest ()
        {
            var logger:TextField = new TextField();
            logger.autoSize = TextFieldAutoSize.LEFT;
            addChild(logger);
            function log(msg:*): void { logger.appendText(msg+"\n"); }
 
            const spr:Sprite = new Sprite();
            const mySpr:MySprite = new MySprite();
            const point:Point = new Point();
            const NUM_ITS:int = 10000000;
            var i:int;
            var beforeTime:int;
 
            beforeTime = getTimer();
            for (i = 0; i < NUM_ITS; ++i)
            {
                spr.x;
            }
            log("Sprite.x: " + (getTimer()-beforeTime));
 
            beforeTime = getTimer();
            for (i = 0; i < NUM_ITS; ++i)
            {
                point.x;
            }
            log("Point.x: " + (getTimer()-beforeTime));
 
            mySpr.updateCache();
            beforeTime = getTimer();
            for (i = 0; i < NUM_ITS; ++i)
            {
                mySpr.cachedX;
            }
            log("MySprite.x: " + (getTimer()-beforeTime));
 
            beforeTime = getTimer();
            for (i = 0; i < NUM_ITS; ++i)
            {
                myPoint.x;
            }
            log("MyPoint.x: " + (getTimer()-beforeTime));
        }
    }
}
import flash.display.*;
class MySprite extends Sprite
{
    public var cachedX:Number;
    public var cachedY:Number;
    public function updateCache(): void
    {
        this.cachedX = this.x;
        this.cachedY = this.y;
    }
}
class MyPoint
{
    private var __x:Number;
    private var __y:Number;
    public function get x(): Number { return __x; }
    public function get y(): Number { return __y; }
}

The results I get are:

Environment Sprite Point MySprite MyPoint
3.0 Ghz Intel Core 2 Duo, 4 GB RAM, Windows XP 153 35 25 62
2.0 Ghz Intel Core 2 Duo, 2 GB RAM, Mac OS X 10.5 295 51 38 98

What a range! The x getter in Sprite makes is about five times slower than the public variable equivalent in Point and MySprite. This is due to the getter function call and the conversion from twisps (thanks to Keith Peters for pointing this out in the comments). Just the plain getter call in MyPoint is almost twice as slow as well. MySprite is an attempt to add the speed of public variables back into Sprite by caching the result of the getter. A real implementation would probably be much more complete, but it should give you a start if you’re interested in swapping convenience for speed.

Since DisplayObjects are so incredibly common in Flash applications and are very likely to be present in performance-critical areas, I strongly recommend revisiting those performance-critical areas if this is news to you. You may end up with a dramatic performance increase!