Tuesday, March 24, 2009

Why native accessors are really bad in Flash Lite.

At work we were discussing what standards we should use for coding. Things like consistency in formatting, naming and having agreed ways of doing things obviously makes everything easier.

So we entered into the discussion of public variables versus native accessors versus custom functions. Here's what I mean when I refer to the different accessors:

native accessor:
public function get width():Numbe{return _width;};
public function set width(value:Number):Void{_width = value;};

public variable:
public var width:Number;

private variable:
private var width:Number;

custom accessor function:

public function getWidth():Number{return _width;};
public function setWidth(value:Number):Void{_width = value;};

The most compelling argument to use custom accessor functions is that public/private variables, and to a lesser extent native accessors, don't allow you to hide your implementation. This is fine and good, but we are using Flash Lite with a resource limited device. In this scenario best coding practice sometimes has to make way for best performance.

So we decided to do some tests to see what the overhead would be of accessing variables one way or another?

Speed Test results in ms, making 10000 gets and sets:

Custom function 2439
Public variable 2394
Private variable 2395
Native accessor 13450

Memory Test results for creating 10000 instances of each class (kb).

Custom function 6528
Public variable 6528
Private variable 6528
Native accessor 6532

In terms of memory, everything is exactly the same except for native accessors.

For performance, the results show that public/private variables were very slightly faster to access compared to custom functions. However, the massive suprise is that native accessors are more than 5 times slower than public/private variables or custom functions. This is truly shocking, and really could completely slow down your application if you used them extensively.

So in many ways our decision about what approach to take with accessors was made really easy; never, ever, use native accessors! The marginal difference between public/private variables and custom variables was deemed insignificant when compared with the benefits of hiding the implementation.

It is possible to justify the use of public variables in some cases. If you have a value object that is strictly read only and has no functionality, then there is nothing to hide in terms of implementation. The only difficulty here is how do you determine that a value object is read only? How do you guarantee that it will never have any functionality going forward?

Labels: ,