Virtual grid and performance degradation.

[Eugene Khosid]

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

[Administrator]

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.

[Eugene Khosid]

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

[Administrator]

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;

[Eugene Khosid]

Thanks Clay,

Nice catch.

Have a good weekend,

Eugene