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

Virtual grid and performance degradation.

Hi all, We''re evaluating various grids to determine which on works faster when the content of the grid changes in real-time (from some data feed). Virtual grid has performed better than all other grids, however we ran into the problem. The test that we run populates the table with data and then updates random cells in the visble rows (50 rows @ 1280x1024). We update 1000 cells in a row in a separate thread. What we see is that the performance decreases with each subsequent run (roughly by 40-50% each time). The memory used doesnt change from run to run and there are no other applications running. I traces it in the profiler and it appears that number of calls to GridIndexDictionary.Contains as well as number of other dictionary related calls in Syncfusion library grows with each run. We''d really like to use this product but we need to resolve this issue first. Any ideas? Thank you, Eugene

4 Replies

AD Administrator Syncfusion Team February 6, 2004 09:09 AM

A couple of thoughts. What do you mean by ''run''? Is the application continuously running, and a run is just an update of 1000 cells. If so, you might try calling grid.ResetVolatileData between ''runs'' to see if that has any affect on things. Are you explicitly setting grid.RowCount or grid.ColCount in your code? In a true virtual grid, these properties never get set (and hence never allocate row/col space). In a virtual grid, these values are always provided dynamically in QueryRowCount an dQueryColCount. If you can attach your test project, we can see if we can spot something here. Or, you can create a Direct Trac support incident and attach the sample to it.


EK Eugene Khosid February 6, 2004 09:33 AM

Clay, Calls to grid.ResetVolatileData didnt have any effect and we''re not setting either RowCount or ColumnCount properties. I attached the code we used to this message. Please take a look at it and see if you can spot the problem. Thanks, Eugene >A couple of thoughts. > >What do you mean by ''run''? Is the application continuously running, and a run is just an update of 1000 cells. If so, you might try calling grid.ResetVolatileData between ''runs'' to see if that has any affect on things. > >Are you explicitly setting grid.RowCount or grid.ColCount in your code? In a true virtual grid, these properties never get set (and hence never allocate row/col space). In a virtual grid, these values are always provided dynamically in QueryRowCount an dQueryColCount. > >If you can attach your test project, we can see if we can spot something here. Or, you can create a Direct Trac support incident and attach the sample to it. SyncFusionGridTestDemo_3729.zip


AD Administrator Syncfusion Team February 6, 2004 10:38 AM

Thank you for the sample. With each click of the update button, you hit this code (just using it as you sent it): blotter.CellChanged += cellChangedDelegate; blotter.RowChanged -= rowChangedDelegate; This means that with each click you are subscribing to CellChange (and you did not unsubscribe to it at the end of the thread). So with each click, you are handling an additional 1000 cells. I added this code at the bottom, and it made things work as you might expect. Debug.WriteLine(m_lblSummary.Text); blotter.CellChanged -= cellChangedDelegate; blotter.RowChanged += rowChangedDelegate;


EK Eugene Khosid February 6, 2004 10:43 AM

Thanks Clay, Nice catch. Have a good weekend, Eugene

Loader.
Live Chat Icon For mobile
Up arrow icon