.:. blog.screenshot.at .:. Flash, Flex, RIA .:. » Mxml

Not easy to use “usePhasedInstantiation”

Manfred Karrer — Wed, 23 Mar 2011 23:47:48 +0000

Have you ever tried to use usePhasedInstantiation? It is not so easy, as you will see…

What is usePhasedInstantiation?
This is a property at the LayoutManager which is used to decide if the methods for the 3 Lifecycle phases (validateProperties, validateSize and validateDisplayList) are deferred with 3 (half-)frames or if they are all executed synchronously in one Frame. So if it is set to true (default state) at an EnterFrame event validateProperties() is called, on the next Render event validateSize() and on the next EnterFrame event validateDisplayList().

As I discussed in a previous blog entry, I was wondering why Flex is using a deferred asynchronous execution model. I tried to find out what happens if you change this property.

First I tracked the executed frames and checked out how it behaves with different use cases of Flex applications:
With a simply Flex application with a few random components it was like expected: 1 Frame delay for the whole cycle (3 half frames).
Then i added much more components and also some really heavy weight components like DataGrid, DateChooser or ColorPicker.
Here it took 3 frames, so it seems that there is some code in some of these Flex components which causes additional invalidation cycles (for instance if you call a invalidateProperties method inside of a creationComplete handler you will trigger a new cycle).
At last I measured with our Spreadbetting application at CMC Markets. Here it was a bit more difficult because there was more complex stuff going on. I measured the executed frames and time it takes until the application was idle in the login state and waiting for user input. We will compare the results later.

I tried to investigate to change this property to see and measure the effects on performance.
But unfortunately it didn´t had any effect. After stepping into the SDK sources, i found the reason:
It is set to true in the Containers createComponentFromDescriptor method which is called for adding the MXML children inside a Container. So it doesn´t help much if you set it to false at any place in the Application, because it will be overwritten by the adding of the first child at any Container class (Canvas, HBox,…).
I am not sure if there is a clean solution how to change this default behavior, but for my test case it was enough to simply ignore the value passed into the setter method in the LayoutManager and set the value to false by default.
But to change the LayoutManager is not so easy. It is setup in the SystemManager and to override this implementation you need to change the SystemManager which can be only defined in an own Application class.

Here are the steps how to do this:

In your MXML Application you use a custom Application class:

[code lang="actionscript3"]
MyApplication defines the custom SystemManager as factoryClass in the "Frame" metadata tag:
[code lang="actionscript3"][Frame(factoryClass="com.test.bootstrap.MySystemManager")]
public class MyApplication extends Application
[/code]
MySystemManager overrides the docFrameHandler method and set MyLayoutManager as implementation class for the ILayoutManager:
[code lang="actionscript3"]public class MySystemManager extends SystemManager {
override mx_internal function docFrameHandler(event:Event = null):void {
  Singleton.registerClass("mx.managers::ILayoutManager",
    Class(getDefinitionByName("com.test.bootstrap::MyLayoutManager")));
  super.mx_internal::docFrameHandler(event);
}
[/code]
In  MyLayoutManager you can bypass the assignment of the usePhasedInstantiation property:
[code lang="actionscript3"]public function set usePhasedInstantiation(value:Boolean):void {
  // for simple testing purpose:
  // simply ignore the values coming from Container and
  // set it by default to false
  value = false;

  if (_usePhasedInstantiation != value) {
    _usePhasedInstantiation=value;
    var sm:ISystemManager=SystemManagerGlobals.topLevelSystemManagers[0];
    var stage:Stage=SystemManagerGlobals.topLevelSystemManagers[0].stage;
    if (stage) {
      if (value) {
        originalFrameRate=stage.frameRate;
        stage.frameRate=1000;
      } else {
        stage.frameRate=originalFrameRate;
      }
    }
  }
}
[/code]
Another interesting detail is that Flex is setting the framerate to 1000 while these phased instantiation is active to speed up the execution (but this could also lead to strange side effects with too fast running animations like we have in our application with a pre-loader animation).
So lets do the tests again with this new setting:

The simple setup showed that all is executed inside of one frame and the time measured showed a faster startup, but the difference was pretty small.

The setup with the more complex Flex components gave a bigger difference in time and of course all was executed in one frame again.

In our CMC application the startup was 400ms faster (2300ms vs. 2700ms).

So 15% faster startup with usePhasedInstantiation set to false in our application startup.
To be honest, I was expecting more. Maybe it is related to the fact that at our application startup (until the login screen) there are not many components created.

I also tried to compare the 2 versions after the user has logged in and under heavy load with a lot of modules and windows open. I could not see a distinct difference but that was probably because of the complexity in this setup caused by a lot of network events.

At least i could not see any problems with rendering. The application was not freezing in any state, so the reason why usePhasedInstantiation was introduced to make the startup more fluidly, does not show any effect in our application.
What is the conclusion?

It does not improve the startup performance much if this property is changed (15% in our application), but I could imagine, when using a lot of components created all at once at startup time, the difference could be stronger. Maybe there could also be problems with freezing the rendering when setting the flag to false.
Even the result is for our use-case not much improvement, it was interesting to see how it is implemented, and to show that Flex is working fine without the deferred lifecycle as well. Also the technique how to exchange the SystemManager and how the implementation for a LayoutManager is configured, was an interesting learning.

A question of style

Manfred Karrer — Fri, 08 Jan 2010 00:03:02 +0000

If you ever had some strange problems with styles in Flex, you might want to know how styles are internally handled and implemented.
Ok this post will not cover too much of all the stuff going on there, but a bit of the basics how styles are finding their way from the css file to your component.

Lets assume that we have a css file with type selectors and class selectors, a module based application and some custom components which are designed the way that you can use them out of the box and that they can be individually skinned and styled by other developers reusing them. That´s what custom components are for, right?

So the first question is:
How are the styles compiled into your swf file?
Assume that they are defined in an external css file. You know you can compile css files to swf files and load them at runtime or simply compile them into your application at compile time with a simple assignment like this:

[code lang="actionscript3"]
 
[/code]

Here is the content of our simple css:

[code lang="actionscript3"]
Button
{
	color: #990000;
}
.myCustomStyle1
{
	color: #009900;
}
 /*
     some additional styles here...
     like Button.myCustomStyle2
*/
[/code]

That´s what we will use for our example here.

In this case the MXML compiler creates a bunch of classes and inserts the css definitions right into a method called from the constructor in the generated Applications class.

[code lang="actionscript3"]
public function StyleExample() {
	mx_internal::_StyleExample_StylesInit();
}
mx_internal function _StyleExample_StylesInit():void {
	var style:CSSStyleDeclaration;
	// Button
	style = StyleManager.getStyleDeclaration("Button");
	if (!style) {
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration("Button", style, false);
	}
	if (style.factory == null) {
		style.factory = function():void {
			this.color = 0x990000;
		};
	}
	// myCustomStyle1
	style = StyleManager.getStyleDeclaration(".myCustomStyle1");
	if (!style)
	{
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration(".myCustomStyle1",
                                           style, false);
	}
	if (style.factory == null)
	{
		style.factory = function():void
		{
			this.color = 0x009900;
		};
	}
	// similar code follows here....
}
[/code]

I only pasted the relevant code, so this is not complete but should give the basic idea.
So what happens here?

A CSSStyleDeclaration is created for the given stylename or class if it´s not already existing in the StyleManager (at a modular application some other application could have already created this style). Then the definitions from the css file (here the color property) are added to the factory function.
It is interesting that the class selectors and type selectors are treated the same way regarding storing the style object in the StyleManager. It is simply the selector name which is used as the key in the _selectors Object (hashtable). Only the “.” in the selector name is the visible difference.

[code lang="actionscript3"]
    public function setStyleDeclaration(
                                selector:String,
                                styleDeclaration:CSSStyleDeclaration,
                                update:Boolean):void
    {
        styleDeclaration.selectorRefCount++;

        _selectors[selector] = styleDeclaration;

        // Flush cache and start over.
        typeSelectorCache = {};

        if (update)
            styleDeclarationsChanged();
    }
[/code]

The CSSStyleDeclaration has also a defaultFactory which is used if there is no factory defined (no css file). Additionally there is an overrides Object which is used to store styles set at runtime vial setStyle(), but this will not be further considered yet.
This leads us to the next part:
How should a default style be applied to a custom component?

How Flex is handling this? The MXML compiler generates a bunch of style classes:
For instance a style class for the Button:

[code lang="actionscript3"]
public class _ButtonStyle
{
    public static function init(fbs:IFlexModuleFactory):void
    {
        var style:CSSStyleDeclaration =
                         StyleManager.getStyleDeclaration("Button");
        if (!style)
        {
            style = new CSSStyleDeclaration();
            StyleManager.setStyleDeclaration("Button", style, false);
        }
        if (style.defaultFactory == null)
        {
            style.defaultFactory = function():void
            {
                this.fontWeight = "bold";
                this.paddingTop = 2;
                this.cornerRadius = 4;
                this.textAlign = "center";
                this.verticalGap = 2;
                this.horizontalGap = 2;
                this.skin = mx.skins.halo.ButtonSkin;
                this.paddingLeft = 10;
                this.paddingBottom = 2;
                this.paddingRight = 10;
            };
        }
    }
}
[/code]

This class is added to the mixins array at the generated _StyleExample_mx_managers_SystemManager class.
The mixins are a strategy to get injected some code at application startup before anything else is instantiated. It calls the static init method, so it is executed before the actual classes constructor is called.
A similar strategy with a static initializer is used in some classes in the datavisualisation package to pack some default styles into a component, so that there is no dependency that there are some styles assigned to the component from outside.
That´s seems to be a pretty nice way to setup the default style a component needs. If the user of the component wants to set some different styles, it can be applied easily via css, styles set in mxml or at runtime via setStyle (if possible, this should be done in the preInitialize phase to avoid performance penalties).

One thing which should be considered when using styles (specially in a large application with modules) is the fact that the style declarations are stored with the selector name as key in an Object (hashtable). So if 2 developers are using the same selector name they end up with a conflict that the later instantiated module will use the already created style and not the one which was compiled to the module.
The same applies if you use the same stylename inside one application, the first one used wins.
To get rid of this problem a kind of namespace strategy can be used ([modulename] + “stylename”). Unfortunately the Flex framework does not give any support for this problem.
Tell me if you know a more elegant solution!

LangDetecten>de YahooC

MXML

DataBinding under the hood (part 3): Generated Code

Manfred Karrer — Sun, 26 Apr 2009 00:28:40 +0000

So now lets get our hands dirty and check out the generated code which is created behind the scenes.

When you compile a Flex application the compiler runs the compilation in 2 steps:

The mxmlc compiler generates a lot of Actionscript classes
The compc compiler compiles from the generated classes plus your custom classes the swf file

These 2 steps are normally not visible, because the generated code is not stored in your project. If you add the compiler argument -keep (or -keep-generated-actionscript=true) in your compiler settings in Flex Builder, you will see a generated folder inside the src folder containing a lot of Actionscript files.

There are different kinds of files generated:

Classes defining the default style for Flex components
Classes holding the Resourcebundle properties
Classes for embedded skins
Classes for Flex Application setup
Classes for Flex DataBinding

The style, skin and property files are out of our scope here and has no direct relation to this topic.
The classes which are used for setting up a Flex Application are our entry point, but will not be discussed in detail (even it would be very interesting to have a closer look to Mixins, [Frame] metadata tags and all these exotic stuff…).

So lets look at our relevant classes for DataBinding (all others has been removed):

The entry-point of our Flex application is _DBGC_mx_managers_SystemManager.
This class extends SystemManager. The SystemManager is the main class and the first DisplayObject added to the stage. It does a lot of setup stuff.
At the first frame in our MovieClip the preloading is handled. At the second frame the Application (DBGC) is instantiated. In the static info() method the mixins classes are defined. At frame 2 the mixin classes are inited via the static method call init().

The DBCG class (file: DBCG-generated.as) is our Application class.
Here the MXML components are converted to UIComponentDescriptors which handles the instantiation of these Components.
At initialize() an array of Binding objects are created.
The Binding class use anonymous functions for resolving the source and destination properties.

[code lang="actionscript3"]
var binding:Binding = new mx.binding.Binding(this,
    function():String
    {
        var result:* = (bindableVO.myBindableProp);
        var stringResult:String = (result == undefined ? null : String(result));
        return stringResult;
    },
    function(_sourceFunctionReturnValue:String):void
    {

        myLabel.text = _sourceFunctionReturnValue;
    },
    "myLabel.text");
[/code]

The _DBGCWatcherSetupUtil creates an array of PropertyWatcher objects, setup the relationship for chains and pass the Binding object to the PropertyWatcher.

[code lang="actionscript3"]
watchers[0] = new mx.binding.PropertyWatcher("bindableVO",
    { propertyChange: true },[ bindings[0] ], propertyGetter);
watchers[1] = new mx.binding.PropertyWatcher("myBindableProp",
    { propertyChange: true },[ bindings[0] ], null);
watchers[0].updateParent(target);
watchers[0].addChild(watchers[1]);
[/code]

After the basic setup execute() is called on every Binding object.
Here is the complete code:

[code lang="actionscript3"]
override public function initialize():void
{
 	mx_internal::setDocumentDescriptor(_documentDescriptor_);

	var bindings:Array = _DBGC_bindingsSetup();
	var watchers:Array = [];

	var target:DBGC = this;

	if (_watcherSetupUtil == null)
	{
		var watcherSetupUtilClass:Object = getDefinitionByName("_DBGCWatcherSetupUtil");
		watcherSetupUtilClass["init"](null);
	}

	_watcherSetupUtil.setup(this,
				function(propertyName:String):* {
                                     return target[propertyName];
                                },
				bindings,
				watchers);

	for (var i:uint = 0; i < bindings.length; i++)
	{
		Binding(bindings[i]).execute();
	}

	mx_internal::_bindings = mx_internal::_bindings.concat(bindings);
	mx_internal::_watchers = mx_internal::_watchers.concat(watchers);

	super.initialize();
}

private function _DBGC_bindingsSetup():Array
{
    var result:Array = [];
    var binding:Binding;

    binding = new mx.binding.Binding(this,
        function():String
        {
            var result:* = (bindableVO.myBindableProp);
            var stringResult:String = (result == undefined ? null : String(result));
            return stringResult;
        },
        function(_sourceFunctionReturnValue:String):void
        {

            myLabel.text = _sourceFunctionReturnValue;
        },
        "myLabel.text");
    result[0] = binding;

    return result;
}
[/code]

So lets jump into the Binding Class. This is a regular Framework class.
The execute() method is basically applying the source value to the destination. In-between there is a lot of error handling going on, but basically it´s nothing else as reading out a value and setting it to the destination. No event dispatching is included until now.

The setting of the value happens on start-up. If the bindable property changes later, event dispatching comes in.
This happens in the PropertyWatcher class:
An event handler is added at the source object and the PropertyWatcher is listening for the defined event type. It is invoked with weak reference, so the fact that MXML Bindings cannot be removed will not lead to memory leaks.
The event handler checks if the dispatched PropertyChangeEvent contains the same property name as our PropertyWatcher represents and calls notifyListeners() if the property name matches.
On every Binding object which is registered as listener watcherFired() is called.
And here again the execute() method is responsible for passing the value from the source over to the destination.

The last missing link is the class which dispatch the PropertyChangeEvent.
The BindableProperty (file: _BindablePropertyVO-binding-generated.as) is the place where this happens.

[code lang="actionscript3"]
[Bindable(event="propertyChange")]
public function get myBindableProp():String
{
    return this._834029286myBindableProp;
}

public function set myBindableProp(value:String):void
{
    var oldValue:Object = this._834029286myBindableProp;
    if (oldValue !== value)
    {
        this._834029286myBindableProp = value;
        this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this,
                                  "myBindableProp", oldValue, value));
    }
}
[/code]

Here the gettter/setters are created for our [Bindable] property. The compiler defines “propertyChange” as event type – [Bindable(event=”propertyChange”)] and dispatches a PropertyChangeEvent if the value has changed.
If the class containing the bindable property is not a subclass of EventDispatcher the compiler set the classes interface of BindableProperty to IEventDispatcher, adds the methods of IEventDispatcher and uses an instance of EventDispatcher via composition.

Note that this code is only generated when you don´t use custom events in the [Bindable] metadata tag ([Bindable(event=”myCustonEvent”)]).

I don´t know how this class is linked into the Application, it has no reference anywhere. I guess the compiler do this job behind the scenes, as well as with the interface classes and some other stuff.

Lets have a look to the moments when DataBinding is executed:

At Application start-up the Binding is executed for the first time.
Here is the call stack (Breakpoint at Binding.execute():

Due the fact that the component is not created yet, the Binding fails in a catch Block at wrapFunctionCall() in the Binding class. The catch block is pretty slow, i am wondering why this initial execute() is not prevented? At least the try/catch could be replaced with a check against null which is much faster then falling into the catch block. I guess in large applications this could noticeable slow down start-up time.

At the time the component is added to the Application executeBinding() is called and triggers the second execute().

At this point the component is valid but there is only the value passed which is defined in the property declaration. This value is often not set at this momens so it is null.

If you setup your initial value at the initialize event a third run will be triggered:

You can prevent this if you set the value right at the variable declaration (if possible) and so prevent to trigger DataBindings third round.

Conclusion
Finally we are through the basic parts how DataBinding is working behind the scenes. To go further it´s best to step through the generated code and try out different scenarios.
We only have had a look into Binding in MXML. If you use BindingUtils just the code for event dispatching from the [Bindable] metadata tag is created.

The generated code for DataBinding with MXML do a lot of error handling. it´s clear that it has some performance drawbacks but gives the benefit that it is very fault-tolerant. You also should consider that there are a lot of different features and use cases for Binding (functions, expressions, 2-way Bindings,…) which has to be handled.

For large applications BindingUtils are the better choice and prevents several performance drawbacks, specially at start-up time.

DataBinding under the hood (part 2): Features

Manfred Karrer — Mon, 20 Apr 2009 21:31:13 +0000

There are many different ways how to use DataBinding.
Beyond the obvious ones there are a few more which could be a nice feature for some weird hacks…

Flex gives us 4 different techniques to use DataBinding:

Curly Brackets in MXML
Binding tag
BindingUtils
ChangeWatcher

Lets have an overview of the possibilities of each technique:

Curly Brackets in MXML

The most obvious one: Binding a source value to a destination value:

This works also for readOnly properties and static constants. You can omit the Bindable metadata tag because the Binding is only triggered at application startup. Static variables are not supported (the Adobe docs are not correct at this). Also Binding to style properties are not supported.

To add 2 way Binding simply use the curly brackets syntax in both objects crosswise:

[code lang="actionscript3"]


[/code]

Here some code examples for Actionscript and E4X expressions:

[code lang="actionscript3"]
// Method calls and calculations


// Perform string concatenation


// Perform a conditional operation using a ternary operator


// E4X expressions

[/code]

A nice feature which is probably not typically used in your daily work, is the possibility to bind to functions. You can use a function as source for your Binding:
To make this work you have to mark the function with the Bindable metadata tag and define your custom event name. When you dispatch an Event with your selected event name the Binding is triggered and the destination gets the return value of your function.

[code lang="actionscript3"]

       


[/code]

As we have seen in the previous post Binding in MXML is not the fastest solution.
Your better choice for writing high performacne applications is BindingUtils:
You have 2 static methods: BindingUtils.bindProperty and BindingUtils.bindSetter

[code lang="actionscript3"]

    





[/code]

The name of the arguments in the API are a little bit confusing (at least for me).

[code lang="actionscript3"]
public static function bindProperty(site:Object, prop:String,
            host:Object, chain:Object,
            commitOnly:Boolean = false):ChangeWatcher
[/code]

The first 2 parameters are the destination object and property name, and the last 2 the source object and property name.

site:Object -> destination object
prop:String -> destination property name
host:Object -> source object
chain:Object -> source property name(s)

Binding supports changes on every bindable element in the source chain. If one element is changing the Binding is triggered.
You can specify the chain as a single String for the name of your property (if there is only one chain element) or as Array of property name Strings for each bindable chain element.

[code lang="actionscript3"]
// bind to object: user.setting.volume
BindingUtils.bindProperty(myText0, "text", user, ["setting", "volume"]);
[/code]

But there is another possibility to set the chain argument:
You can pass an Object in the form:

[code lang="actionscript3"]
{ name: propertyName,
  getter: function(host) { return host[propertyName] }
}
[/code]

This Object must contain the name of the property and a function returning a value, which is normally a getter function for a public bindable property of the source object.
This feature opens interesting possibilities.
The function is basically a wrapper which returns the value of the source. I am not sure at the moment where to use this, but it´s good to know that there is an open door…

When using chains with BindingUtils you can choose if the chain elements in-between are bindable.
If an element in-between is not bindable, no Binding is triggered if this element changes.
This is not the case when you use the chains in MXML. You got a compiler warning and a runtime exception if one of the in-between elements are not marked as bindable.

Here is a code example for using chains:

[code lang="actionscript3"]



public class User
{
    [Bindable]
    public var setting:Setting;
    public function User(setting:Setting)
    {
        this.setting = setting;
    }
}

public class Setting
{
    [Bindable]
    public var title:String = "blabla";
    public function Setting()
    {
        setInterval(function():void {
                     title = int(Math.random()*10000).toString()
                     }, 100);
    }
}
[/code]

The ChangeWatcher is the class used inside of BindingUtils. ChangeWatcher implements the event handling and the handling for the chains. BindingUtils are just a more convenience way and adds nearly no overhead compared to use ChangeWatcher directly.

Here are some additional snippets about DataBinding:
You can use multiple [Bindable] tags. Doing this lets you trigger Binding from different events.

When you use Binding in MXML the addEventListener method uses a weak reference.
This is important due the fact that you cannot unbind with the curly brackets syntax. Without weak reference Binding in MXML would be a potential memory leak.

When using BindingUtils you are responsible for calling the unwatch() method on your ChangeWatcher object (a ChangeWatcher object is the return value of BindingUtils.bindProperty). The addEventListener method in the ChangeWatcher is not using weak references, so if you don´t do your housekeeping carefully, this could lead to a memory leak.

In UIComponent there is the method executeBindings() which force a trigger to all Bindings on this component. This could help sometimes when a Binding is not firing by it´self correctly, but of course should be taken carefully because it´s probably just healing a symptom not the underlying problem.

When you use the [Bindable] metadata tag before a class definition, it only applies to public properties; it does not apply to private or protected properties, or to properties defined in any other namespace. You must insert the [Bindable] metadata tag before a nonpublic property to make it usable as the source for a data binding expression.

The DataBinding reference can be found at Adobe LiveDocs.

DataBinding under the hood (part 1): Performance

Manfred Karrer — Sat, 18 Apr 2009 21:21:05 +0000

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.