We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

Right approach for updating large amount of data to the grid

Thread ID:

Created:

Updated:

Platform:

Replies:

72214 Mar 9,2008 03:31 PM Mar 10,2008 04:37 PM Windows Forms 1
loading
Tags: Grouping
Pradeep Kellangere
Asked On March 9, 2008 03:31 PM

Hi,

When the application comes up, we are binding a DataTable to the grid. The datatable doesn't have any records at this stage.

The user will search the data which results in thousands of records. Once the data is received, the xml data is transformed into a DataTable. During this transformation, since the data is getting added to the datatable, the grid starts refreshing.

To avoid this refresh of the grid, I'm using the Grid.BeginUpdate() when the transformation starts and call the EndUpdate once it completes. One issue here is when I call the EndUpdate(true), the application is kind of hung, meaning, it doesn't proceed with running any other statements which is after the EndUpdate. EndUpdate(false) works perfectly fine, but the documentation for 'false' mentions that it should discard the paint changes. What's wrong here ?

The other approach I was using before was to clone the datatable attached to the grid and then transform the DataTable and then reset the DataSource of the grid. I wasn't comfortable with resetting datasource and calling refresh everytime as I will need to provide auto refresh capabilities to the grid (meaning receives the data using notification and need to update the grid directly).

Which is the right approach ? Performance is the highest concern here.

Regards

Pradeep


Administrator [Syncfusion]
Replied On March 10, 2008 04:37 PM

Hi Rudy,

There are some standard optimizations that need to be set, which will let you speed up the grouping engine and correct such performance problems, when many rows are present. Please try the following optimization settings for your GridGroupingControl.

void OptimizeGridSettings(GridGroupingControl grid)
{
grid.CounterLogic = EngineCounters.YAmount;
grid.AllowedOptimizations = EngineOptimizations.DisableCounters | EngineOptimizations.RecordsAsDisplayElements;
grid.UseDefaultsForFasterDrawing = true; // GDI interop drawing, FirstNRecords Summaries
grid.InvalidateAllWhenListChanged = false; // only paint modified cells
grid.InsertRemoveBehavior = GridListChangedInsertRemoveBehavior.ScrollWithImmediateUpdate;
grid.UpdateDisplayFrequency = 50; // update every number of ms (speciy 0 if Update should occur manually, 1 if immediately)
//grid.TableControl.EnableDoubleBufferSurface(); // reduce flickering

// Instruct grouping control not to access datasource through
// CurrencyManager API and instead access list diretly. When set to
// false you wil howver loose support for built-in CurrencyManager
// synchronization.
grid.BindToCurrencyManager = false;
}

Also refer to the below forum thread for EngineOptimization and counter.
http://www.syncfusion.com/support/forums/message.aspx?MessageID=26047

Take a look at the performance based samples in GridGroupingControl from the shipped browser samples
\Syncfusion\EssentialStudio\6.1.0.34\Windows\Grid.Grouping.Windows\Samples\2.0\PerformanceSamples\

Also 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.

Best regards,
Haneef


CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;