Flex : How expensive pretty looking DataGrids are?

In software world - especially while thriving on Rapid Application Development, people start with prototype development. Under the influence of re-usability - developers land up using the same prototype to build the application framework. At this point in time - probably none would have anticipated the scalability and the volume of data. A small application works like grand-ma and end users get pissed!


Whole gamut of changes has brought the Flex DataGrids to work very slow for an intranet based application.


We ran into this classic case of short-sighted-ness in recent past. Clients came to us frustrated about "performance" of Flex DataGrid implementation in various modules in our application.


While analyzing - we realized that

1. there were way too many containers used in hierarchical fashion in the layout
2. Data Grids were using labels for displaying the data and applying dynamic styling
3. Item Renderer implementation of Labels was such that it would cause
4. Large amount of data was being transferred over XML from server to the client application

Let's take an example of each of them:

1) Too many contain hierarchies
The way flex layout and children component display works is by applying algorithms to determine x, y position and preferred size and styling. When a flash player runs out of a browser - it is at mercy of memory allocated to browser instance. The more it has to do with limited resources, the more time it will take i.e. degraded performance.


2) Labels as Item renderers in data grids
Think about it from a different perspective. We have a data grid with 45 rows and 28 columns. Based on the display region out of 1260 - required number of label objects will be initialized. The re-draw logic on flex display may invoke various methods on all these object instances even on a mouse move! Even if the execution time for each of them is in milliseconds, multiply it with number of cells visible and you will see how performance degrades.



3) Item renderer implementation

A Label used as ItemRenderer is fine but one has to be mindful of how best to use it? I am sure one cannot call start extending the component by including Label in MXML script and initialize the attribute of Label to cause method calls for colors and text e.g. following declaration may not be a great way to initialize a Label that will be used as itemRenderer.

<mx:Label xmlns:mx="http://www.adobe.com/2006/mxml" color="{(String)(getColorCode(data))}" text="{ getLabelText(data ) }" >


4) Large amount of data transfer between browser and server
Think of a couple of thousands of lines with 38 columns each to be retrieved - be converted to java objects - java objects be converted to XML format - xml be sent to the client - client to parse the xml within memory allocation limits - generate collection of local data types...
There is possibly a scope of improvement 1) to avoid converting the java object to xml and back by switching to binary data transfer and 2) Using a faster data transfer protocols like AMF.

Conclusion:
I would only want to imphasise the importance of giving enough weightage to trivial looking things from beginning and to address the issues in rightest possible way to avoid aging of application and ensuring of scalability.