Jack Viers has posted a great performance comparision between Flex 3 to Flex 4 components.

Unfortunately the Flex 4 components suffer from big performance decrease (163% slower). But just read the article it is very profound discussed there.

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.
			

After working 10 years with Flash and 3 years with Flex I am still not convinced that the Flex Life Cycle is necessary.

I discussed this topic already with many developers but nobody could really give me a satisfying answer.
So I spread out my thoughts now to the public in the hope to get some valuable feedback.

Of course I am familiar with the concept of the Flex Life Cycle and the “elastic racetrack” behavior of the Flash Player.

The reason why I am not a friend of this concept is because it introduces an asynchronous code execution where a synchronous code execution would be much easier and faster.

In all my ActionScript based projects it was never necessary to use this pattern and defer code execution to another frame (or Render Event).
At bwin we have built a similar application as the current Flex-based Live Betting application previously in AS2, with a lot of complex components and auto layout containers, without running into any serious problems.
And to be honest the performance of the AS2 project felt somehow the same as the Flex version. But AS3 is about 10 times faster (of course that´s a bit too simple said and we did not measure the difference, but I am not the only one complaining about poor Flex Performance).

So isn´t it valid to question the concepts Flex is based on?

I am sure the architects at Adobe have had good reasons why they decided to introduce this pattern.
In the Docs and Blogosphere one can find several papers about it, but none of these explanations satisfied me, and some are not telling the full truth (that code execution is deferred to another frame).

So I try to discuss some assumptions for possible reasons:

• Avoid Performance bottlenecks
• Keep the Frame-rendering fluidly
• Avoid Performance penalty from unintended repeated method (setter) calls
• Pattern for separating different concerns
• Problems with reading out the measurements of DisplayObjects before they are rendered on screen
• Problems with complex execution flow from auto-layout containers code

So let me add my thought to these points:
Avoid Performance bottlenecks

That was my first assumption when I started with Flex, that this pattern is used to avoid performance bottlenecks. First I thought there is a hidden mechanism for detecting code execution which is running too long and delay this execution to the next frame. After checking out the SDK code I found out that it is simply delaying the 3 phases to 3 “half-frames” (Render Events and Enter Frame Events). So if you have really heavy code your player is still freezing up for a certain time and the Life Cycle does not give you any support for solving this problem.

That leads to the next argument:
Keep the Frame-rendering fluidly

Delaying the render code to the next frame helps the Flash Player running more smoothly and fluidly. That is basically true, but in my opinion 90% of the time the Life Cycle is wasting performance. For me it is a bad trade to get maybe at startup time some more fluidly running pre-loader animation but startup time takes much longer.

Why the Life Cycle is wasting Performance?
Because code which normally would be executed in one frame is now executed over 2 frames (or more).

There is another related issue with performance:
Avoid Performance penalty from unintended repeated method (setter) calls

Assume that in a large project it could be hard to control the execution flow so that it could happen that setting a text or layout property to a component is not only applied once but unintended multiple times.
For this scenario the Life Cycle helps because the call to the setter of the property is relatively cheap, so if the setter is called 10 times instead of once it will not hurt much. Then at commitProperties the property is only applied once to the component.
Again some weird scenarios with multiple invocations of commitProperties will not hurt much because the applying of the property to the component should be protected by a “changed” flag (see best practice with the Flex Life Cycle).
Also if you need for layout code some measurements the pattern helps to avoid unnecessary and repeated code executions.
BUT – is poorly written code really the reason why this pattern was introduced? It is true that it gives you some kind of fault tolerance, performance-wise. I guess this argument should not count in professional software development, and in fact it is dangerous because it could hide some deeper problems. If your setters are called more then once, why not look for the reason and clean it up?
I know in complex situations this could be sometimes hard, and under real life circumstances and time pressure you have to deal with something like this. But it should not count as a criteria for such a basic framework design decision.

I made also some measurements to check out the performance penalties for repeatedly called setters:

With 100 000 iterations applying a changing text to a TextField (in a AS3 project) I got these results:

1. Case:
Setting the text property to a variable in a loop and then applying the already stored text to the TextField again in a loop:

[code lang="actionscript3"]setText(): 119ms
applyStoredText(): 481ms
[/code]

In contrast to applying the property directly to the TextField:

[code lang="actionscript3"]
setAndApplyText(): 2879ms
[/code]

So you can see it is much slower in the 2. Case, so the Life Cycle really helps here, because it only applies the last stored property and not the changing values in between. But again – setting multiple times unnecessary property values is another problem.

The same test with setting the x position does not deliver such a big difference, in fact it is nearly the same time consumed (40+52 vs. 114)

[code lang="actionscript3"]setXPos(): 40ms
applyStoredXPos(): 52ms
setAndApplyXPos(): 114ms
[/code]

Let´s continue with the next point:
Pattern for separating different concerns

To have a kind of pattern which separates different concerns is basically a cool thing. So you have your code block for setting properties, another method where the properties are applied to the component, a method where the measurement is defined and another one for the layout code.

I have no really argument against this pattern, but I don´t know why it is necessary to defer some code of these phases to the next Frame. The execution of the Life Cycle methods could have been triggered also at the Render Event, then there would not have been any delay to another frame, even it still would add this nasty asynchrony.

So this pattern could make development easier but introduce asynchronous behavior where we lived in a beautiful synchronous Flash world before. In my opinion: Not a good trade.

What else?
Problems with reading out the measurements of DisplayObjects before they are rendered on screen

Remembering back to some of my Flash projects I have had sometimes strange problems with TextFields and measurement when setting text and using autosize. But I could not reproduce these problems in a test case anymore. So I am not sure if that was caused by some other stuff or maybe by differences in some older Flash Player versions? But at least in my situations these problems could always be solved without deferring code to another Frame. But at this point I am not sure if there are certain use cases where you cannot read out the size of a DisplayObject (TextField) before it is actually rendered to the screen. If there are such cases this would be a valid argument, but then I am wondering why this could not be solved on the Flash Player level instead of solving this problem at a Framework level.

And my last point:
Problems with complex execution flow from auto-layout containers code

I can imagine that complex situations with nested auto layout containers could be sometimes really tricky to handle. To avoid recursions or unnecessary calls for any possible situation in a generic framework is a tough challenge.

But also in complex situations it is a deterministic behavior, so it should be possible to solve this without the Life Cycle pattern as well. From my experience there was no problems with auto layout containers, but of course in normal project development you have limited use cases and we were not forced to deal with all the possible use cases, like Flex has to do as a generic framework.

So finally I don´t have any idea for the real reason why Adobe has introduced the Life Cycle.
Maybe it seemed that it could help solving a lot of tricky problems (auto layout containers, mixing MXML with AS code,…) and was considered as a good pattern to make development easier. Maybe the fact that Flash has a strong support for Event driven programming and the Flash developers are already used to handle this asynchrony, led to this decision?
Maybe is was a strategic decision to make Flex easier for new developers without Flash background, who were not familiar with the Flash Players frame-based execution model?

I don´t know. I really would appreciate if someone from the Flex Team could illuminate this topic.

I just have made the experience that many things where much more transparent, cleaner and faster in pure ActionScript then in Flex, and i think the Life Cycle is one of the reasons for that.
I really like the API of Flex but I am wondering why Adobe don´t give more attention to performance, specially for large scale applications.

Any comments or insights are highly appreciated!

P.S.: Just found an interesting post related to this. I 100% agree what Paul Taylor says about UIComponent, but that is another story. Ever heard about Reflex? Sounds pretty promising!

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?
(Read more…)

At my first posts I wrote about my favorite Flex feature: Databinding
Now I will take a look at the opposite, IMHO the most precarious “feature” in Flex: callLater()

If you have a dodgy problem that a certain property is not available when it already should be and you ask someone at flexcoders you often get the advice, “try callLater” for a quick work-around. Sometimes this helps, but it leaves a bad smell, because often it´s just hiding some other problems in the code.
So when we worked on a large-scale Flex application we have used it sometimes in the beginning, but after a while we decided to avoid callLater. To find and solve the real problem is simply the better solution – and we never needed it again – there was always another solution to solve a particular problem (maybe we just have had luck).

Unpleasantly we get confronted with the fact that callLater is used inside the Framework at the heart of the layout engine.
We struggled with some strange problems. For instance we got a NullPointer exception in the updateDisplayList method of a custom component, which has already been cleaned up properly and removed from the displayList. It turned out that the layout mechanism delayed with callLater an invocation of updateDisplayList but our stuff there has already been removed and threw an exception.
It was not hard to fix, but it demonstrated us that some asynchronous stuff was going on behind the scenes which was out of our direct control.

So for me callLater leaves always a certain bad smell.

Unfortunately I never found time to really investigate how it´s implemented and what are the concepts behind it.
So it was time to catch up with this issue:
CallLater is basically a method in UIComponent which delays a passed function to the next EnterFrame OR Render event.
Often in den docs it´s just described that it will delay to the next frame, which is not correct because it could be that your function is executed already at the Render Event, which happens in the same frame and is the last opportunity where User code can be executed before the screen is rendered.

For more details about the internal concept of a frame in Flash and the relevant events see the great article by Sean Christmann:

Here is a good illustration from his article about the anatomy of a frame in Flash:
(Read more…)