Accessibility

Flex Article

 

Flex Application Performance: Tips and Techniques for Improving Client Application Performance


Table of Contents

  1. Introduction
  2. Architecting Flex Applications That Perform Well
  3. A Note About Flash Players
  4. Using Layouts, Hierarchy, and Containment Properly
  5. Examples of Common Container Redundancies to Avoid
  6. Using Deferred Instantiation to Improve Perceived Performance
  7. Handling Large Data Sets
  8. Playing Complex Effects Smoothly
  9. Achieving Great Performance with Runtime Styles
  10. Using Dynamically Repeating Controls for Better Performance
  11. Improving a Repeater Object's Performance
  12. Improving Performance of Charting Components
  13. Performance Tuning and Profiling Your Own Flex Application
  14. Using Runtime Shared Libraries (RSLs)
  15. Feedback and Support
Comments

Improving a Repeater Object's Performance

There are a few things to think about if you need to improve your Repeater object's performance. First, if you are using containers as the child of the Repeater object, check whether using a HorizontalList or TileList control would be better. If that is not the case, ensure that the containers used as the children of the Repeater do not have unnecessary container nesting and are as trim as possible. If a single instance of the repeated view takes a noticeable time to instantiate, repeating makes it worse. As mentioned previously in this article, multiple Grid containers in a Repeater object do not perform well because Grid containers themselves are resource-intensive containers to instantiate. An alternative solution is to try a List control with a custom cell renderer or the HorizontalList or TileList controls.

You should also set the recycleChildren property to true to improve a Repeater object's performance. The recycleChildren property is a boolean value that, when set to true, binds new data items into existing Repeater children, incrementally creates new children if there are more data items, and destroys extra children that are no longer required.

When you set this property to false, the Repeater object recreates all the repeated objects when you swap dataProvider properties, sort, and so on, which causes a performance lag. The FlexStore sample application has an example of recycleChildren at play. When you load the application, notice the Sort by option under the product thumbnail view. This enables users to sort the product thumbnails based on name or price. The ordering of the Repeater object's dataProvider property is what changes, the thumbnail views do not. By setting the recycleChildren property to true, the Repeater object does not recreate each thumbnail view; it simply reshuffles the dataProvider property based on name or price.

The default value of the recycleChildren property is false to ensure that you do not leave stale state information in a repeated instance. For example, suppose you use a Repeater object to display photo images and each Image control has an associated NumericStepper control for how many prints you want to order. Some of the state information, such as the image, comes from the dataProvider property, while other state information, such as the print count, is set by user interaction. If you set the recycleChildren property to true and page through the photos by incrementing the Repeater object's startingIndex value, the Image controls bind to the new images, but the NumericStepper control maintains the old information! You should use recycleChildren="false" only if it is too cumbersome to reset the state information manually, or if you are confident that modifying your dataProvider property should not trigger a recreation of the Repeater object's children.

This may go without saying, but the recycleChildren property has no effect on a Repeater object's speed when the Repeater object loads the first time. The recycleChildren property only improves performance for subsequent Repeater occurrences. If you know that your Repeater object will only create children once, there is no need to use the recycleChildren property or worry about the stale state situation.

Improving Performance of Charting Components

Flex provides a very robust library of charting components that give you a two-dimensional visual representation of your data. These charting components follow the same guidelines as other Flex components, including the same performance drawbacks.

The Flex charts have been designed to perform well. All charts cache intermediary values in the transformation from data to screen, so that only the minimum amount of recalculation occurs in response to any change to the data or chart. The most expensive actions to perform in Flex charts is forcing a chart to redraw an axis, or forcing a chart to recalculate its labels. In fact, it is faster to resize a chart than to change its dataProvider (a change that requires a chart to potentially redraw an axis or recalculate labels). Below are further tips that you can use to improve the performance of your Flex charting components.

  • When possible, set the filterData property to false. In the transformation from data to screen coordinates, the various Series types filter the incoming data to remove any missing values or values outside the range of the chart that would render incorrectly if drawn to the screen. For example, a chart representing vacation time for each week in 2003 might not have a value for the July fourth weekend since the company was closed. If you know your data model will not have any missing values at runtime, or values that fall outside the chart’s data range, you can instruct a series to explicitly skip the filtering step by setting its filterData property to false, earning you a small performance boost.
  • If possible, don’t let a LinearAxis autocalculate its range. A LinearAxis calculating its numeric range can be a costly calculation. If you know reasonable minimum/maximum values for the range of your LinearAxis, specifying them help your charts render quicker. Also, specifying an interval (the numeric distance between label values along the axis) value improves performance.
  • Have your CategoryAxis dataProvider and Series dataProvider refer to different objects. Modifying a CategoryAxis object’s dataProvider is more expensive than modifying a Series object's dataProvider. If the data bound to your chart is going to change, but the categories in your chart will stay static, have the CategoryAxis' dataProvider and Series' dataProvider refer to different objects. This prevents the CategoryAxis from reevaluating its dataProvider, which is a resource-intensive computation.
  • Improve render time of your AxisRenderers by setting particular styles. The AxisRenderers perform many calculations to make sure they render correctly in all situations. The more help you can give them in restricting their options, the faster they will render. Explicitly setting the following styles on the AxisRenderer will improve performance: labelRotation and canStagger. You can set these styles within the tag or in CSS.
  • Specify gutter styles when possible. The gutter area of a Cartesian chart is the area between the margins and the actual axis lines. With default values, the chart adjusts the gutter values to accommodate axis decorations. Calculating these gutter values can be resource intensive. By explicitly setting gutterLeft, gutterRight, gutterTop, and gutterBottom values, your charts draw quicker and more efficiently.
  • DropShadows are optional; if you don’t need them don’t use them. The default HALO styles for BarSeries, ColumnSeries, and LineSeries use ShadowRenderers. ShadowRenderers draw drop shadows beneath the data elements. If DropShadows are not necessary, switch to the Simple renderers (SimpleBoxRenderer for ColumnSeries and BarSeries, SimpleLineRenderer for LineSeries); this improves the rendering speed of your charts.

 

Page 10 of 12
Previous Page
Next Page