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.
Best Answer
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!