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

GDBG Perf..

Hi Clay, I have created a sample project demonstrating a real time updates..even though the frequency of update is configured to 100 ms but in reality it differs anywhere from 300-400 and we do lot of compacting and throttling on data. i have attached the project zip file.. If you look at Form3 form in which i have placed both DataGrid and GridDataBoundGrid binded to a datatable. First click on Load Data this will populate rows in datatable and after that click on update button this will initaite a update that is triggered every 100 ms. since the update is frequent so we will see some shoot up in cpu usage. DataGrid - 10-12% GridDataBoundGrid - 50-60% This result surprised me.. as GDBG cpu usage is constant whereas DataGrid tends to win over here.. so would appreciate if you have a look in the code and let me know if i am missing something... On other hand insertion of data in descending order (new row always appears in top ) was very impressive with GDBG. assuming we are receiving 450 rows per second.. DataGrid after 3K was dead.. ( i suspect it couldn''t keep up with pace.. if i reduce the update timer from 100 ms to somewhere between 500 it survied till 6K ).. Using GDBG the CPU usage swinged between 15-30% and was constant after that .. very impressive result.. unless i am missing something :-) Another thing i have noticed is there are no updates performed on grid if it is out of user sight.. this is pretty good feature.. do you expose an event that is raised when grid goes both in suspend and resume state.. because if we subscribe to this event we can notify to server to stop sending us the data.. that in turn would further scale up our server side processing. As GDBG update seems to consume time compared to DataGrid and in our trading scenario there are frequent updates compared to insertion.. so would appreciate if u can take a look into this matter. Regards Yogi GridCheck_7963.zip

1 Reply

AD Administrator Syncfusion Team February 21, 2005 09:12 AM UTC

The way your sample is set up, you would get better performance calling grid.BeginUpdate(BeginUpdateOptions.Invalidate) before the loop and grid.EndUpdate(ture) after the loop. The performance gains I see on my system with this change makes the cpu load move to the same range as the datagrid. In your actual application, if you are updating random cells across random rows every 400msecs (as opposed to sequentially updating all cells), then you may get better performance not using Begin/EndUpdate.

Live Chat Icon For mobile
Up arrow icon