Forum

When using very large cell counts(250,000+), ColumnRemoveAll() and RowRemoveAll() are slow (5-10 seconds).  Can you recommend a quicker way of completely emptying a grid, thanks.

Almost entirely CExtGridCellStringDM ... these have been replaced with CExtGridCellString which sees a great improvement in de-allocation performance ... 2x infact.

De-allocation is still 2-3x slower than allocation though!

... correction ... I’ve just timed it and its 5 x slower!

We need to know the cell types you are using in your tests.

I’m finding de-allocation is much slower than allocation, around 10 times slower!

I beleive something is wrong somewhere as destroying the window de-allocates the grid immediately, where as ColumnRemoveAll() and RowRemoveAll() are really slow.

Any suggestions?

I’ll take a look at that, thanks.

Allocating grid cells & populating them is very quick, its deleting them that is slow.  If I close the dialogbox the grid is destroyed immediately, can this not be done whilst the dialogbox is still open?

The CExtGridWnd control (and other controls derived from it ) does everything the grid should do. But it does not keep its grid cells. It keeps only a CExtGridDataProvider-based data provider object which manages a two dimensional array of grid cells and does some additional actions like sorting (and grouping in the case of report grid control). By default, the CExtGridWnd control uses the CExtGridDataProviderMemory memory data provider component which allocates all the range of grid cells in memory without any virtual caching and data uploading. All the CExtGridCell-based grid cell instances are allocated/deleted using custom C++ new/delete operators with a IMalloc* interface pointer to the memory manager object. We do not use the memory manager provided by COM. We have our own one implemented in the CExtGridAlloc class. Our memory manager works much faster because of support for block-based memory allocations. The speed of allocation and de-allocation should be close to each other. It should very depend on how heavy are constructors and destructors of grid cell classes. You can override the CExtGridWnd::OnGridQueryDataProvider() virtual method and proved an externally stored instance of data provider to your grid control(s). You can use one data provider instance with more than one grid control. This allows you to re-use grid cells without re-creating them.

The CExtFormulaGridWnd control demonstrated in the FormulaGrid sample uses a very specific data provider we call a sparse data provider. It’s virtually cached in both horizontal and vertical directions. All grid cells are allocated only at first attempt to get a CExtGridCell* pointer for any cell location including outer row/column headers. You can use the CExtGridDataProviderSparse-derived data provider in your grid control.

The AdoRecodsetView sample demonstrates a vertically cached grid control which keeps only those data cells that are visible on the screen. The data cells are uploaded dynamically when grid is scrolled or re-sized vertically. It uses a recordset data provider. Here is an editable version of this app: http://www.prof-uis.com/download/forums/AdoRecordsetEdit.zip
Here is another example of recordset data provider based grid control: http://www.prof-uis.com/download/forums/CacheableGrid2.zip