Working with Large Data Sets in Flash Player

Flash Player does a very good job in rendering of small to medium data collections. But some enterprise applications need to offer the users to manipulate with tens of thousands of records. One of the projects of recent efforts of Farata Systems is extending standard Adobe Flex collections to make them faster. We call them “lazy collections” because they bring the data to the client in a lazy fashion – only when the user requests them.  This approach allows creating responsive UI that renders large sets of data without causing delays on the UI.
In Flash Player based RIA, non-responsiveness in data manipulations is usually caused by one of the following:
1.    Slow retrieval of the data set from the storage (e.g. slow response from DBMS).
2.    Limited network bandwidth or use of inefficient network protocols
3.    Poor data rendering to the UI components (UI freezes)

In this blog I’ll be talking about the poor data rendering. Typically, we create RIA where Adobe Flex communicates with the server-side Java using the AMF protocol (Java to ActionScript serialization via BlazeDS).  AMF is an efficient HTTP-based protocol for transferring strongly-typed data (Java Data Transfer Objects).  But on the UI side you may start experiencing slowness even on medium-size data grids displaying 500 rows by 50 columns. Add to such grid poorly written item renderers  (with nested containers) and Flash Player quickly becomes a bad guy.

It’s hard to find a Flex enterprise application that doesn’t use DataGrid, and it has to offer responsive UI and smooth scrolling of the data collections that serve as a Model in the MVC-based environment.  When BlazeDS deserilizes large amounts of Java bytes into ActionScript objects, the users may experience a freezing effect, when the UI is not responding to any user’s actions until the serialization is over. The reason being that Flash Player performs this deserialization in the same thread as UI rendering.

When the size of a data collection becomes large (e.g. 30 thousand of ActionScript objects), it’s better to find a way of not bringing all the data at once to Flash Player. This is the main idea of our lazy collections.  It’s about combining smart data pagination and scrolling.

You don’t want to load the entire data set into the Java server’s memory to avoid crashing it. While preparing the screencast that demonstrates advantages of our lazy collections vs. the standard ActionScript ArrayCollection, I had to increase the amount of heap memory on my Tomcat server to prevent Java’s OutOfMemory exceptions – and I was the only user sending data requests to the server! What is a hundred users will cause the server load into memory datasets of a 100Mb each? You need to provide at least 10Gb of memory on the server.

We decided to create data collections that use pagination on the server in conjunction with the smarter collections on the Flex client. We have created beta versions of collections supporting both Halo and Spark Flex components. Even though we are extending standard Flex collections, the processing of the asynchronously arriving data is different in Halo and Spark. Halo’s components are heavier, but smarter when it comes to asynchronous data retrieval. The standard Flex framework (without LCDS support) doesn’t offer any support of lazy loaded collections, and we had to follow our usual path – adding the missing features to BlazeDS.  These are our main collections:

LazyIndexedList – a subclass of ActionScript ArrayList that loads the data objects on demand. For example, the initial data set may contain only a hundred out of fifty thousand objects. If the user scrolls the data in the data grid component and hits the last object of this first hundred, the LazyIndexedList will automatically request the next hundred from the server.

HugeIndexedList adds the ability to unload unused data from memory. This class  monitors the current scrolling position to avoid unloading the data being viewed.

There is some work in progress to complete the functionality required by the Spark’s AsyncListView collection. In the future, these classes will be included in our Clear Toolkit set of components. Meanwhile, you can watch this 9-minute video to see these collections in action.

Valery Silaev

6 thoughts on “Working with Large Data Sets in Flash Player

  1. Look at the Flex UI base classes and you’ll know why everything is so slow. Need performance? Avoid Flex completely, just run pure AS3.

  2. “When BlazeDS deserilizes large amounts of Java bytes into ActionScript objects, the users may will experience a freezing effect, when the UI is not responding to any user’s actions until the serialization is over. The reason being that Flash Player performs this deserialization in the same thread as UI rendering.”

    Multi-threading in Flash Player would make a complete difference in this scenario, where the data deserialization could be handled in another thread. I hope it’s included in Flash Player 11…

  3. Tom,

    Our LazyIndexedList does work with default AsyncListView, Halo mx:DataGrid and Spark s:DataGrid.

    The HugeIndexedList has two extra requirements:
    – “UI List” must fire SCROLL event (Halo mx:DataGrid and mx:List do this out of the box, while Spark counterparts require small extension)
    AsyncListView must not persist placeholders for pending items. So we need our own implementation.

    By the way, we developed AsyncCollectionView as well: default AsyncListView doesn’t implement ICollectionView and w/out it Spark DataGrid can not sort columns.

    James Ward has seriosly reworked his implementation at GitHub in comparison to initial version (described in blog post). He moved far away from that basic prototype, changed the responsibilities between classes etc.

    So now James’ and our implementation has a lot of similarities, however there are 2 important advatages in our implementation:
    1. Our list has necessary support for cancellation of in-progress requests to load data. For LazyIndexedList this occurs only when list is reset via assigning different length. But for HugeIndexedList that is derived from LazyIndexedList this is absolutely critical during scrolling.
    2. Our list resolves actual length automatically, while in James impl. it must be assigned from application code.


  4. NJT,

    Taken your statement to extreme we could agree that the only way to write efficient (in terms of performance) programs is to use ASM and target every specific platform separately. Unfortunately, this severely impacts productivity. So I would argue that performance/productivity trade-off provided by Flex is good enough for business applications, though game dev. and alike is more preferable with vanila AS3.


Comments are closed.