Andrew Trice

Monday June 26, 2006

Flex Framerate & Performance

A word of advice: Increase the default framerate in your flex applications to squeeze as much performance as possible out of them.

The performance of a flex application is directly related to the framerate of the compiled swf in your flex application. I have a few examples here that demonstrate this pretty well. Each example is actually comprised of 2 flex applications placed side by side. The code for each application each is identical (per example), except for one thing... I have changed the frameRate of the mx:Application component to show the effect that the framerate has on overall application performance. One application has a frameRate="1" and the other has a frameRate="99". 99 is a very high value for a frame rate in flex, but it is not too high... It really is a target frame rate. If the Flash player is unable to maintain a framerate of 99 fps, it will go as high as it can to get closest to 99 fps. I recommend using a frameRate of 99 on all flex applications.

When placed side by side, the effects are obvious.

Take a look at my first example.

Here, you will see a panel that is constantly being resized using states and transitions. The transition is a parallel transition using mx:Resize and mx:Move elements, each with a duration of 400 milliseconds. You would expect that these transitions really do execute at exactly 400 milliseconds b/c they have that duration defined programmatically. Well, that is not exactly the case. In each panel, you will see 3 text boxes. The first and second text boxes aren't really important... The third IS quite important though. The third text box shows the number of milliseconds that it took to actually complete the transition effect. You will notice that, on average, the application with the lower framerate actually takes more time to complete the transition. Common sense will tell you that the application with the lower framerate should be faster than the application with the higher framerate b/c the computer shouldn't have to work as hard to paint so many screens in the same time period. Common sense is wrong here. The flash player actually throttles code execution based on the framerate of the application. Not only is the transition duration shorter in the application with the higher framerate, but the animation is also much smoother.

---

Here's my second example.

In this example, I used actionscript to calculate values of a Fibonacci Sequence up to 10^1000 (10x10x10... 1000 times). In each application, the sequence is calculated 100 times (50 times positive, 50 times negative). You'll notice a lag when the app initializes... That is because the Fibonacci numbers are being calculated. Once the application is initialized, you can see the total execution time to calculate the sequences. The differences in time are trivial. On my machine, both applications calculate the sequence in about 1300 milliseconds. This shows my next point: The execution of actionscript code that is not dependant upon displayed elements is relatively unaffected. The execution of code this is dependant upon a displayed element is significantly affected. Try using the scrollbars to view the results in each application. You will notice that the scrolling in the application with the higher framerate is much smoother and much quicker.

---

Here's my last example.

This example shows the instantiation of complex nested components. You'll notice that the instantiation/initialization times are very similar... not too big of a difference there, and not necessarily repeatable. What you will notice it a huge difference in usability of the two applications. The application with the slower frame rate is not nearly as responsive to user interaction, such as button clicks, combo box selection, color controls, scrolling, etc...

So, I'll repeat myself again:
A word of advice: Increase the default framerate in your flex applications to squeeze as much performance as possible out of them.

Download the source for these examples.