Performance

[Dominic Morris]

RE: Scrolling performance, when using the grid bound to a DataTable.

Performance on my 3Ghz P4 when scrolling a grid with lots of columns (~20) and rows (~1000), when the grid is taking up all of the screen so that all (or most) of the columns are visible [very important], is terrible.

Truly, very bad performance; e.g. if I click in the scollbar area to pagedown or pageup, there''s almost 0.5s delay before anything happens. As for dragging the thumbtrack... ugh.

I''ve noticed that if the grid is populated directly with the same # of cells (i.e. not bound to a DataTable) then perf. is much, much better.

Is there anything that I can do to increase the bound scrolling performance? There seems to be excessive overhead in accessing the DataTable at render-time. Does the grid cache any of this data?

Thanks,
DM.

[Administrator]

Which version are you using? There was a bug with a previous version which slowed down the grid the more columns it had (exponentially). That said with the current version there are no knows issues at this time with regards to that. Of course a grouping grid will always be scrolling slower than a regular GridControl because of the complex/dynamic nature of the hierarchical data. We continuously try to improve performance so make sure you use the latest version. Some things to try with latest version: You could try GridGroupingGrid.Engine.AllowCacheStyles and Enable this flag if you want GridRecordRow and GridCaptionRow elements to keep a cache with style information for individual cells and reduce the number of QueryCellStyleInfo calls being raised for these cells. Other things you could look at is overriding Table.ShouldCacheRecordData. Here is how the base class version looks like:

		/// 

		/// Method is called when the table tries to determine whether a record''s underlying data row can be cached
		/// within  objects.
		/// 
		/// True if record''s underlying data row can be cached
		/// within  objects; False otherwise.
		protected virtual bool ShouldCacheRecordData() // called when SourceList is changed
		{
			return ((SourceList) is IGroupingList) && ((IGroupingList) SourceList).AllowItemReference || SourceList is System.Data.DataView;
		}

Another setting is Engine.AllowSwapDataViewWithDataTableList. It Gets / sets if the engine can wrap access to a DataTable with a which provides optimized access to the rows of the datatable. Engine will access a DataTable through this wrapper class instead of accessing records through the DataTable.DefaultView to increase performance when adding, removing, and changing records when Engine.AllowSwapDataViewWithDataTableList is enabled. Default is False. --- but that should normally not affect scrolling. Take also a look at the GroupingPerf example. If you derive the engine you could optimize things also bit by reducing the number of elements indiviual groups are reserving. (See OnInitializeSections in that sample). Stefan

[Dominic Morris]

Hi Stefan, Thanks for the detailed response. I''ll be sure to take a look at your suggestions. I''m using v2.1.0.9. Is that the latest? >Which version are you using? > >There was a bug with a previous version which slowed down the grid the more columns it had (exponentially). > >That said with the current version there are no knows issues at this time with regards to that. Of course a grouping grid will always be scrolling slower than a regular GridControl because of the complex/dynamic nature of the hierarchical data. We continuously try to improve performance so make sure you use the latest version. > >Some things to try with latest version: > >You could try GridGroupingGrid.Engine.AllowCacheStyles and Enable this flag if you want GridRecordRow and GridCaptionRow elements to keep a cache with style information for individual cells and reduce the number of QueryCellStyleInfo calls being raised for these cells. > >Other things you could look at is overriding Table.ShouldCacheRecordData. > >Here is how the base class version looks like: > >

>		/// 

>		/// Method is called when the table tries to determine whether a record''s underlying data row can be cached
>		/// within  objects.
>		/// 
>		/// True if record''s underlying data row can be cached
>		/// within  objects; False otherwise.
>		protected virtual bool ShouldCacheRecordData() // called when SourceList is changed
>		{
>			return ((SourceList) is IGroupingList) && ((IGroupingList) SourceList).AllowItemReference || SourceList is System.Data.DataView;
>		}
>

> >Another setting is Engine.AllowSwapDataViewWithDataTableList. It Gets / sets if the engine can wrap access to a DataTable with a which provides optimized access to the rows of the datatable. Engine will access a DataTable through this wrapper class instead of accessing records through the DataTable.DefaultView to increase performance when adding, removing, and changing records when Engine.AllowSwapDataViewWithDataTableList is enabled. Default is False. --- but that should normally not affect scrolling. > >Take also a look at the GroupingPerf example. If you derive the engine you could optimize things also bit by reducing the number of elements indiviual groups are reserving. (See OnInitializeSections in that sample). > >Stefan >

[Administrator]

QueryStyleInfo is called very often. It seems that it is executed for each cell in the grid no matter if cell is visible for user or not.
How to determine in QueryStyleInfo event method if cell is visible for user?
I want to update cell style only for these cells which are displayed
to the user. When user scrolldown than cell style will be updated. I want to make sure that I'm updating cell style on demand not all cells in the grid.

[Jisha Joy]

Hi Adam,

Please refer to the following browser sample that illustrates code for a volatile data container that is optimized for non-virtual grids with few number of rows, where the QueryCellInfo event gets called only once for a cell and not multiple times


..\Windows\Grid.Windows\Samples\2.0\Performance\OTO Query Cell Info Demo\cs


Regards,
Jisha