When working with huge amounts of data on DataGroup, SkinnableDataContainer and all its Subclasses you will notice degradation in performance. Manipulating Data becomes slower, the UI on the Groups become less responsive, startup suffers, footprint is huge. By default, Felx 4 creates an ItemRenderer for each data-item resulting in this overhead.
The solution is to use virtualization on the layout of the dataGroup. By setting useVirtualLayout=true, ItemRenderers are recycled, the performance will be fine even for 100′000 and more records (depending on complexity).
There are a couple of things to considerate:
- Since ItemRenderers are recycled you must take care of updating the components in your renderer to the correct state, so that they reflect the underlying data (i.e If the data + states, that a player is a midfielder and you have a checkbox for this in your renderer, then make sure to set the state of this checkbox based on the underlying data, that is + passed down). Also, the data object being pushed down from the Host-Component to the ItemRenderer could be null, so we have to check for this as well, preventing NPEs.+
- Measurement will be approximate, either based on the first element, or a typical element you can reference or by setting rowHeight when using variableRowHeight=false.+
- One drawback of virtualization is that when using the itemRendererFunction property, the renderers arent recycled. The function is expected to create an Instance (wra+ pped in a + ClassFactory) of an appropriate renderer for the data-item being passed. I haven’t looked into this, but there could be a way of creating your own ItemRenderer pool a+ nd returni+ ng + an suitable renderer from that pool.+
- Checking the Profile, you’ll see tha+ t with virtualization the Renderers get reused, when virtualization is off, you’ll get as many Renderers as you have records.+
- Another disadvantage is that virtual+ ized layouts do not respect layout element’s includeInLayout property.+
- In the Design Specification it is stated that “Virtual layouts with small numbers of items whose sizes vary dramatically will respond poorly to interactive thumb scrolling. + Responsiveness will improve as the variation in size decreases and/or the length of the list increases”. In the test I did, I could not find any problems with poor responsiveness in scrolling, yet.
My findings are, that in practice the performance is very good on huge data sets when virtualization is used. The drawbacks can be handled or are neglectable in many situation where thousands of rows must be used.