Andrew Trice
Real-World Rich Internet Applications
Tuesday May 26, 2009
Excerpt: Application Performance Strategies
Here's an excerpt from my new book "Professional Flex 3", Chapter 67: Application Performance Strategies. There is a ton of useful material in this book, from 8 authors -- almost 1500 pages worth!
Chapter 67: Application Performance Strategies
There’s no question about it, everyone wants their application to be the fastest. It should start up quickly, it should load data quickly, it should render data quickly, it should be able to crunch numbers quickly, and it should not use much memory. When developing your Flex applications, it is often easy to overlook simple pitfalls that can be detrimental to your application’s performance. This chapter highlights strategies for building applications that perform well and identifies simple mistakes that can cause large impacts on application performance.
Understanding Object Creation Policies
One small change that can have a potentially disastrous affect on application startup performance is changing the creation policy of a container object. By default, all container objects use a deferred creation policy. This means that objects are only created as they are needed.
For example, consider a TabNavigator component. If TabNavigator contains multiple children, only the children of the first tab are actually created upon initialization of the tab navigator instance. In the following code snippet, only the children of the first canvas would be created upon initialization.
<mx:TabNavigator> <mx:Canvas label="Tab 1"> <!-- various child components here --> </mx:Canvas> <mx:Canvas label="Tab 2"> <!-- various child components here --> </mx:Canvas> <mx:Canvas label="Tab 3"> <!-- various child components here --> </mx:Canvas> </mx:TabNavigator>The children of the second and third tabs are only created when they are accessed. The default creation policy is the preferred creation policy in the vast majority of situations. Rarely, you may encounter a scenario where you change the creationPolicy value from auto (deferred instantiation) to all.
When the creation policy is set to all, all child objects of the container are created upon initialization. In the previous example, all three tabs, and all of their children, would be created when the TabNavigator instance is created. If there are very few children in each tab, the impact of this is minimal; however, if each tab contains complex components or complex nested components, this can have a dramatic effect on application initialization.
It is very easy to overlook this and set creationpolicy to all. In some cases simply setting this policy can cause the application to lock up for upwards of 15 to 30 seconds while the child components are being created, depending on their complexity. It is very important to only use the all creation policy under specific and limited use cases.
Structuring Data for Performance
Another extremely important factor in creating applications that perform well is the structure and complexity of the data that is used within the application. In general, a Flex user interface is designed to render data and provide a visual interface for the user to interact with. It is not designed to perform heavy number crunching or data transformations. Requiring a Flex application to perform major calculations and transformations of data will always result in an application that performs slower than an application that does not require any data processing. For this reason alone, it is extremely important to maintain high fidelity between the data and the visual interface.
Servers are orders of magnitude more efficient than the Flash Player at performing complex calculations and transformations, and should be used for those tasks whenever available. Data should always be transformed on the server and serialized to the Flex user interface in a format that is easy to consume and display. Any processing resources that are utilized transforming data on the user interface will not be spent rendering the interface or handling any events, thus yielding an application client interface that is less responsive.
Lazy Loading Data
The structure of the data is not the only factor that can impact how the performance of the application. How the data is loaded can have as big an impact on application performance as anything else. When I refer to how the data is loaded, I don’t mean the serialization method (AMF remoting, XML over HTTP, or SOAP Web Services); this technique applies to all three serialization methods.Lazy loading of data is the process of only loading data as you need it, as opposed to loading all data initially. Consider an application that loads thousands of records of data. Regardless of whether you are using AMF Remoting or XML, it will always be faster to return a minimal data set, rather than load every attribute o of every record, especially when all attributes of the data are not visible in the current view.
Consider an application that loads contact information for thousands of contacts and displays them in a data grid, although the data grid displays only the first, middle, and last names. Following are two separate versions of XML data that is used to populate the grid. The first version of the XML contains all information regarding that contact. Each record contains the contact name, plus additional data that is not necessary to display within the grid.
The following is a trimmed-down version of the same data. For each record, only the name values are loaded. Any time that you want to drill down into the data, the complete data for that record would be retrieved based on the contact ID.
Multiply these XML records by thousands of records, and it’s easy to see how lazy loading can make a difference. With the compacted data, the size of the data being transferred from the client to the server is reduced by more than half, thus reducing the overall data load and transfer time. Additionally, the data is less complex, so it can be parsed faster in the client interface, and it runs faster at runtime since the XML objects are simpler.
Impacts of Multiple Service Invocations
Another important factor to keep in mind when creating your Flex applications is how the data is loaded into the application. You will want to minimize the number of service calls required to load a particular data set. This should not be confused with the lazy loading of data. Lazy-loaded data should be used whenever possible.Instead, this refers to using multiple service invocations to load a single data set. Consider the contact list discussed in the previous section. You would not want a scenario where you have to use multiple service invocations to load that list. For example, first you load information about the currently logged-in user, then load the user’s permissions list, and finally load the contacts list based on the permissions list.
Instead, you would simply want to load the list in one service method. You should have a single service method that takes the ID of the current user, handles the permissions on the backend, and returns the contact list to the client interface.
Every additional service request causes latency as a result of server processing and network lag. The more chained requests, the larger the delay will be, and the slower your application will respond. The backend services should always be structured to return the necessary data from a single service invocation.
This chapter goes on to include information about managing memory references and event listeners, weakly referenced events, maps, associative arrays, index arrays, frame rates, bitmap caching, object allocation, and object recycling. Be sure to go to your local bookstore and grab a copy.
Available in stores in June, or on Amazon Today!
http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470223642.html
http://www.amazon.com/Professional-Adobe-Flex-Joseph-Balderson/dp/0470223642
