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. Image for the cookie policy date

[JH] Performance Issue: Updating Single Column in 10000Records Vs Recreating New Data Table

Hi everyone I''m using v2.1.0.9 of GGC and am experiencing some major differences in performance. We using a DataTable as a DataSource for a grid with about 10,000 rows. Our application lets the user toggle the numeric value for a certain column - this is quite a complex calculation that needs to be done to update the column value for all records - so can''t use derived columns I''ve noticed that if I recreate the DataTable from scratch each time it takes about 5 seconds (includes creation, populating and binding to Grid)- which is fine I''ve just tried a different approach whereby I loop through all of the rows in DataTable and just update the column value that''s changed. I thought this would have been super efficient but it''s taking about 60 seconds rather than the 5 seconds to create from scratch. The only real difference is that I use Rows[index] enumerator to get the required row and update the column value - as oppose to cretaing a new row and adding to end of DataRowCollection I''ve used BeginUpdate, BeginLoadData and EndLoadData on both methods. I''m just wondering if there''s a bit more I need to do - could you suggest some events that I could hook into - I suspect things might be firing in the grid or Binder. Or perhaps IsDirty etc. There appears to be so many possible areas Thanks again for the great support Jason

4 Replies

AD Administrator Syncfusion Team December 13, 2004 08:05 PM UTC

Jason, Try this: this.groupingGrid.BeginUpdate() this.groupingGrid.Table.TableDirty = true -- make your changes this.groupingGrid.EndUpdate(false) this.groupingGrid.Refresh() TableDirty = true tells the grid that the table is dirty and subsequent ListChanged events can be ignored. Otherwise each change you make to the DataTable will result in realtime updating of counters and summaries of the table. (Each time a Log2(n) operation which is good if you do a few updates but not if you know you are looping through the whole table anyway ...). So, with TableDirty = true, the operation count will be n. Without TableDirty = true it will be n*log2(n). Stefan


JH Jason Hales December 14, 2004 09:05 AM UTC

Thanks for the info, Stefan. I did what you suggested but it''s still just as slow. I put in some additional event handlers for: grid.Table.SourceListListChanged grid.SourceListRecordChanging grid.Table.DisplayElementChanging grid.Table.SourceListRecordChanged and noticed that each one gets fired for each row updated. Is there a way to tell the grid not to fire these events - or are they a bit of blind alley for my performance issues? As a test I tried cloning the source dataset and just updating the data in the cloned copy and that runs in less thna 5 seconds so it seems to be related to updating the bound data table Thanks again Jason >Jason, > >Try this: > >this.groupingGrid.BeginUpdate() >this.groupingGrid.Table.TableDirty = true > >-- make your changes > >this.groupingGrid.EndUpdate(false) >this.groupingGrid.Refresh() > > >TableDirty = true tells the grid that the table is dirty and subsequent ListChanged events can be ignored. > >Otherwise each change you make to the DataTable will result in realtime updating of counters and summaries of the table. (Each time a Log2(n) operation which is good if you do a few updates but not if you know you are looping through the whole table anyway ...). > >So, with TableDirty = true, the operation count will be n. Without TableDirty = true it will be n*log2(n). > >Stefan >


JH Jason Hales December 14, 2004 10:30 AM UTC

I''m just reading through my previous releated (and forgotten) comments on Support/Forums/message.aspx?MessageID=18496 There''s some good ideas there but if you can add any more that would be great thanks Jason


JH Jason Hales December 14, 2004 11:40 AM UTC

I think I''ve found the answer. I didn''t give the complete story as I thought it was not necessary... I have a abstract Refresh class which ensures only overriden method gets called (aka Template Method Pattern) in the correct order. Essentially it was doing the following (all via Invoke): Step 1: syncGrid.Parent.Enabled = false; Step 2: syncGrid.BeginUpdate(); syncGrid.Table.TableDirty = true; syncGrid.Table.SummariesDirty = true; Step 3: dataTable.BeginLoadData(); RefreshData(); // Call the abstract method dataTable.EndLoadData(); Step 4: UpdateSyncGrid() // abstract display/filter changes Step 5: syncGrid.EndUpdate(false); syncGrid.Refresh(); Step 6: syncGrid.Parent.Enabled = true; syncGrid.Enabled = true; By swapping Step 5 and 6 over, to re-enable the grid before the endupdate the performance is now back to 5 seconds - rather than 60 seconds Jason

Loader.
Live Chat Icon For mobile
Up arrow icon