DataBinding under the hood (part 1): Performance

DataBinding is one of the favorite features of Flex. It makes development fast and is really nice to use. In the following posts we will have a closer look to some different aspects of DataBinding.

• Performance
• Features (beyond the obvious ones)
• Generated Code under the hood

So lets start first with a closer look at Performance:
It is clear that such a nice feature has it´s overhead.
For small and medium applications this probably will not be even noticeable. The benefit´s for rapid development will knock out the performance considerations. But when you work on larger applications you may come to a point where you have to take care of every possible bottleneck. And the sum of a lot of small improvements will give you a considerable performance boost at the end.

Lets have a look to different approaches to set a value from a source to a destination object:

• Binding in MXML with the curly brackets (or the Bindable tag)
• Using BindingUtils (or ChangeWatcher) in Actionscript
• Custom Event dispatching
• Setting the property directly

I created some tests passing a random value from a source to a destination with 10 000 iterations and repeated this tests 10 times to get a good average value.
Here are the results:

• Binding in MXML: 412 ms
• BindingUtils: 188 ms
• Event dispatching: 146 ms
• Write property directly: 81 ms

So there is a considerable performance penalty when using Binding in MXML. For small projects this probably will not be a problem, in large applications where a lot of Bindings are triggered, this could be a noticeable drawback. It could slow down the application startup, when all Bindings are initiated.
A good thing on MXML Binding is that it gives you the highest level of pre defined errorhandling. Because most of the generated code can be checked at compile time, it gives you warnings if you going to mess up something. With BindingUtils the possibility of runtime errors is already higher.
Another plus for MXML is that some features are only supported with MXML Bindings (Actionscript expressions, E4X Expressions,…).

The difference between BindingUtils and EventDispatching is not so huge, but in some cases you can gain a bit if you handle it by your own event dispatching.

The fastest way of course is setting a property directly and could be your good friend in really performance critical areas. But the support for a loosely coupled architecture is not as good as with the other solutions.

There are some further fine-grained improvements possible when using your own event name instead of the default “propertyChange” event. In the Bindable metadata tag you can specify a custom event name.

[code lang=”actionscript”][Bindable (event=”myCustomEventName”)][/code]

Doing this, the Flex Compiler will not auto-generate code for you, like it is the case when you use [Bindable] without setting an event name. So you have to write a bit more code and dispatch an Event with the given event name. But doing this you can gain some performance improvements.

Here are the test results:

• BindingUtils with custom event names ([Bindable (event=”myCustomEvent”)]): 150 ms
• BindingUtils with the default (“propertyChange”) event name ([Bindable]): 188 ms

Doesn´t sounds too exciting, but that´s not all:
When you have a large class with a lot of bindable properties the performance gain will grow with the number of properties, because all Binding objects have to be checked if one property in this class will change.

Separating properties with custom event names, will speed up performance again.

The test scenario:
Change 10 different properties in one class with 10 custom events versus changing 10 properties in a class with the default event name (do 10 000 iterations).

Here are the test results:

• Test Binding with different Event names: 1511 ms
• Test Binding with the default “propertyChange” event name: 2657 ms

So now the difference is quite huge.
Of course to have too much properties in one class is often a result of bad design and should not be the typical use case. But it´s good to know where to tweak if performance issues arise.

Here is the code you have to write by yourself if you use custom events.
It is basically the same the compiler auto-generates for you when you use [Bindable] without a custom event name.

[code lang="actionscript3"]
private var _myLabelText:String;
[Bindable(event="myLabelTextChanged")]
public function get myLabelText():String
{
    return _myLabelText;
}
public function set myLabelText(value:String):void
{
    if (_myLabelText !== value)
    {
        _myLabelText = value;
        dispatchEvent(new Event("myLabelTextChanged "));
    }
}
[/code]

References:
Watch out the great presentation about DataBinding by Michael Labriola: Diving in the Data Binding Waters
Links: Slides

It´s also worth to have a closer look to the DataBinding reference at Adobe LiveDocs.

The test project is linked here, in the View Source context menu the sources are attached.

Comments (4)

Category: Actionscript,Flash,Flex

Sorry, the comment form is closed at this time.