Firemonkey and large amounts of data

Question

I just had a look at Firemonkey's grid implementation and it turns out that it is a very simple implementation (only 1800 lines which seems not much for a grid implementation). It does almost no custom painting but does instead aggregate a lot of other controls - which seems to be the Firemonkey style of doing things.

For example, each column keeps an array of controls - one for each cell. For a normal text column with 1,000,000 rows, the grid would keep 1,000,000 edit controls in memory - which seems a little crazy to me. (EDIT: not so sure now if that assumption is right. It seems to take the visibility of cells into account, which could mean it does provide something like a virtual mode, but I'm not quite sure...)

My question: Without any doubt, this component-aggregating design of Firemonkey seems simple and elegant but does it really scale well with the amount of data that has to be displayed in the grid? I cannot imagine that it does perform well with a large number of rows. What is the Firemonkey way of handling large amounts of data?

Thanks for any input.

Annecy

The key to FireMonkey's success will be adoption/commitment by third party component builders IMO, ie., DevExpress, TMS, etc. FireMonkey provides an environment that can produce native crossplatform apps and this is BIG. Hopefully, some of these component builders will commit (come on DevExpress say something positive...) some significant resources to this end. I'm excited at the potential of this framework but I'm not going to be able to produce anything meaningful until I have my favorite third party controls on my pallet. (I build grid based client-server apps) – Jerilynjeritah

@Bob A DevExpress already stated (community.devexpress.com/blogs/ctodx/archive/2011/08/18/…) that they have no plans for Firemonkey controls. If adapting controls really requires a complete rewrite (which seems to be the common opinion), then I'm pretty sure TMS will not release within the next months as well. – Annecy

My instincts are that component vendors will be very wary about committing to FMX whilst it is in it's current state. I think they'll wait to see which way the wind blows before investing valuable resources on what could easily be another white elephant. – Nereen

@David - OS X and IOS platforms are an attractive carrot and FMX is the vehicle to get there. I'm thinking they will come around sooner rather than later... – Jerilynjeritah

@Bob I'd agree if the signs were good that FMX was of sufficient quality. Whilst it clearly has potential, all indications I have seen suggest it needs a lot more refinement before it's ready for primetime. – Nereen

Why don't you fill the grid with one million rows and see what it means in memory and other resources consumption? – Telemetry

Answer 1

The FireMonkey grid only has controls for the number of visible lines. So if you have a grid with 10 visible rows and 3 columns, it will create 30 cell controls. Filling the grid with 10.000 records is no problem: when you scroll the 30 cell controls are reused and mapped to the new visible rows.

And yes: I did some tests with this because we have TMS grids with 100.000 records :-).

If you use OnGetCellText (so not TStringgrid, which is very slow with lots of records, especially TMS grid (based in VCL stringgrid)) it is very fast (OnGetCellText only retrieves data of visible cells). We use this technique in combination with our data objects (these are already loaded, so no need to fill each cell of the grid with the string value again...) and both TMS and FMX grids are very fast with 100.000 records or more!

Darr

Thanks! I tried TGrid with OnGetValue event. Adding large number of nodes seems reasonably fast but somewhere at 20.000 items it stops working (no text visible). Also scrolling seems very buggy. – Annecy

Do you have a demo project? I can create a QC for that. – Bounteous

All I did is to place a TGrid on a form, set the RowCount to 25,000 in FromCreate and did Value := 'Blub' in OnGetValue event. – Annecy

@Smasher: also note that the controls used by FireMonkey generally do not have window handles, so they are pretty lightweight. They are completely done in code. And the re-use of such controls in a grid is similar to how Apple's Cocoa does it. There, a control is merely a container for one or more "cells" which take care of drawing, etc. A Cocoa NSTableView has a queue of cells which are re-used when the view changes, and they only cover the visible (and clickable) area of the entire grid. – Bardo

strange, TGrid with 1 column and 25000 rows with OnGetValue = 'test' jsut works... – Bounteous

On my system it works even with 500000 rows. But the same exe on a different system cuts at 19047 rows. I think it can only be a hardware dependent problem. Perhaps the DirectX version? – Cubical