Firemonkey and large amounts of data

12
votes

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.

1
delphidelphi-xe2firemonkey
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) – Bob A
@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. – jpfollenius
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. – David Heffernan
@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... – Bob A
@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. – David Heffernan

1 Answers

11
votes

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!