I''m using v22.214.171.124 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
ADAdministrator Syncfusion Team December 13, 2004 03:05 PM
this.groupingGrid.Table.TableDirty = true
-- make your changes
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).
JHJason HalesDecember 14, 2004 04:05 AM
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:
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
>this.groupingGrid.Table.TableDirty = true
>-- make your changes
>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).
JHJason HalesDecember 14, 2004 05:30 AM
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
JHJason HalesDecember 14, 2004 06:40 AM
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):
syncGrid.Parent.Enabled = false;
syncGrid.Table.TableDirty = true; syncGrid.Table.SummariesDirty = true;
RefreshData(); // Call the abstract method
UpdateSyncGrid() // abstract display/filter changes
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