DataGrid performance strategies

Performance can quickly become a major concern when you are using the DataGrid component because the size of the data it displays can be scalable. A data grid that displays a hundred rows on a fast computer with a fast connection to the data source may look acceptable to you. A month later, when the data has increased to several thousand rows, a user may have a much different experience. Also, the user may have a slower computer on a slow connection to your data source.

Here are some suggestions for avoiding common performance pitfalls when using the DataGrid component.

Build and bind a data structure rather than add columns directly.
There are two ways to add columns and data to the DataGrid component: by binding a pre-made data structure (an array of objects) through the DataGrid.dataProvider property or by using DataGrid class methods such as DataGrid.addColumn() and DataGrid.addItem(). Whenever possible, you should bind to a pre-made data structure using the DataGrid.dataProvider property because it allows DataGrid to create all the columns it needs before attempting to draw them on the screen.

You may be tempted to make a for loop to call DataGrid.addColumn() for all the columns needed. Although this seems like a simple and obvious approach, do not use it. Each time that DataGrid.addColumn() is called, the data grid adds event listeners, sorts, and redraws itself to present the new column. Creating 20 columns using DataGrid.addColumn() causes DataGrid to sort itself and redraw 20 times needlessly. Building your data structure in ActionScript requires no rendering or events to account for. When you assign it to the dataProvider property of the DataGrid component, all of the drawing is completed in just one pass.
Provide a drill-down mechanism for detailed data.
The DataGrid component interface allows users to search quickly so that they can search for more details. Provide only the data needed to perform the initial search, and.detailed information for any particular row or cell can be provided in a second search step. This process minimizes not only the initial data required to fill the data grid but also minimizes the amount of information that users must read to locate what they are looking for. When a row or item of interest is selected in the data grid, a second call can be made to the data source to get related details. Those details can be appear better in some other UI mechanism, such as a collection of multiline text fields and graphics.
Avoid cycles of data manipulation between the data source and the data grid.
If it is possible, and if it meets long-term database needs, storing the data in much the same format and order in which it appears can avoid unnecessary memory allocation and processing time on the user's computer and speed up data-grid response time.
Avoid queries that return every row in the database.
Users rarely want to see every record that is available every time they access the data. It's important to understand what the consumers of your data are looking for and give them the means to narrow down their search. If they usually look only at the most recent records for a given week for a particular subject, display that smaller group of data as a default, with the ability to widen the view of the data.

Consider paging potentially large amounts of data to limit its size by providing a subset of data that might normally be returned from a query. For instance, rather than viewing all 10,000 rows of data that might be returned by a query from your database, a subset of the first 20 rows might be called for, and additional navigation buttons might trigger a call to fill the data grid with the next 20 records.
Separate data processing from CellRenderer processing.
The CellRenderer API lets you display custom cell content in a data grid. A functional requirement might require that you populate the data grid with a ComboBox component or other UI control conditionally. For example, based on a selection in column two, you may repopulate or auto-select options in column four. Whenever possible, it is important to separate this conditional logic and repopulating of controls from the process of rendering the content of the cell. Each time the mouse rolls over the cell, the cell is selected, or data is changed, the content of the cell or the entire cell is likely to be redrawn to keep it up to date. This means that any code you put in CellRenderer is run over and over again, so you should keep processing in CellRenderer as light as possible. If you do have to add code to CellRenderer, it is better to call a function from CellRenderer that detects what updates need to be made and makes them in the most efficient manner.
Use UIObject.doLater() to access properties after the data grid has finished drawing.
A data grid instance needs to finish drawing and loading data before you can access all the properties of the data grid (such as focusedCell and others). Because there is no "complete" event for a DataGrid, you can use UIObject.doLater(), instead, to call a function that accesses the data grid properties. UIObject.doLater() will execute the function only after the data grid properties are available. See DataGrid.focusedCell for an example.

View comments on LiveDocs