Isse with memory and refresh

Hi, Issue#1 Is there any issue with memory required by the grid? Some time I feel loading of the grid very slow. I was trying to run the sample GridGroupingTutorial/GroupingPerf and evey time I hit “Load Grid” button I get the following numbers Process''s physical memory usage: 36163 kb Process''s physical memory usage: 48742 kb Process''s physical memory usage: 52883 kb This number keeps increases on every click on “Load Grid” button without changing any value. Same thing happens in the sample DtatBound/GridPerf. It keeps increases the memory usages. Three different people are evaluating the grid and everyone has this feeling that it is slow and keeps increases the memory usages. Issue#2 There is one more issue if you run sample DtatBound/GridPerf and click on “Virtual grid ” Button and try to increase the with of column on header but it does not refresh until you click on a cell. Need the your input. thanks

I''m sure someone from Syncfusion will comment on this, but I ran the sample that you refer to on my machine and the "mem usage" task manager column is staying pretty close to 42,500 K. I did a single minimize/restore to force the OS to trim the working set after the first load of the grid, not sure if you did that. I''m not sure on your requirements, but I have the 1.6.1.8 Syncfusion components in use @ 50 client sites and have never had a problem with the performance of the grids (some of which are used to show result sets with several thousand rows and 20 + columns). Just my $.02, Sean

I appreciate your reply. I was looking the statistics in the display/resualt area provided by the sample itself and every time memore usages increase by 1.5 times. Outpot looks like Results: ----------- OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00 Repaint/Sizing: 00:00:00.0468780 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 32358 kb OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00 Repaint/Sizing: 00:00:00.0468780 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 32870 kb OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00.0156260 Repaint/Sizing: 00:00:00.0312520 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 34463 kb OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00 Repaint/Sizing: 00:00:00.0468780 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 34942 kb OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00 Repaint/Sizing: 00:00:00.0468780 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 35074 kb OptimizedListChanged=True DataTableList=False Autosize=False ScrollWindow=True Fill Datatable: 00:00:00.1406340 Set data source and categorize: 00:00:00 Repaint/Sizing: 00:00:00.0468780 Total time: 00:00:00.1875120 Total Row Count 20000 Process''s physical memory usage: 35074 kb I didn''t not use the memory task mmanager. what is the purpose of "Process''s physical memory usage" ? what does it shows? This is really very impt. issue for us and may be for others too. please do reply!

The problem with the virtual grid not drawing properly is due to a coding error. In InitializeGrid, instead of this.grid.BeginUpdate(); this.gridPanel.Controls.Add(this.grid); this.grid.ResetVolatileData(); this.grid.Update(); the code should have been: this.grid.BeginUpdate(); this.gridPanel.Controls.Add(this.grid); this.grid.ResetVolatileData(); this.grid.EndUpdate(); //changed.... As far as the memory usage goes, for the GriddataBoundGrid, right-click the textbox that is logging the and do a SelectAll and Delete to clear this between Load clicks. I think doing this will stabalize that memory number after teh 3rd click. It will fluctuate up and down, but should not grow without decreaing as garbage collection is done. In the GridGroupingGrid, there was a leak in the 2.0.5.0. Some improvements to this problem were made in 2.0.5.1 public patch, and even more improvement in a 2.0.5.36 private patch. What version are you using? If you want to try the private patch, submit a Direct Trac support incident requesting it. But you should also try clicking the load button 5 or 6 times to make sure the memory is still growing at the point.

why so "As far as the memory usage goes, for the GriddataBoundGrid, right-click the textbox that is logging the and do a SelectAll and Delete to clear this between Load clicks. I think doing this will stabalize that memory number after teh 3rd click. It will fluctuate up and down, but should not grow without decreaing as garbage collection is done." i tried and after 3rd click it does not grow. and what does it have to do with deleteing from logging are? I have to expalin all this to my boss. thanks

I just noticed one more thing. If you load your grid for 20K rows it takes around 34MB and then if you increase the row count to 200K it takes 117MB. But if you decrease the row count to 20K, still the memory usages is 120MB and more. so it keeps moving up on any change does not matter whether you increase or decrease the row count? This Looks like a VERY SERIOUS ISSUE. Please help.

What version are you using? >>what does it have to do with deleteing from logging are? The text in in the log window is growing with each click unless you delete it between clicks.

I am using 2.0.5.1. thanks

Between pressing the LoadGrid button, try pressing the ResetGrid button. This will zero out the memory. So, load 20K rows, press reset, load 120K rows, press reset, and load 20K rows.

Reseting works for 20K and 200K. Still it is leaking some memory first three times. are you looking into this or it is know thing over you side? Please help. thanks

Here are the numbers I see when I click load followed by reset 12 times. There is a jump between 1 and 2, but this is due to internal tables being populated. From 2 on, the behavior looks consistent consistent with standard garbage collection behavior. Now these numbers are from runing a release build. Debug builds have separate memory overheads that may vary. 1 Process''s physical memory usage: 44838 kb Process''s physical memory usage: 45588 kb 2 Process''s physical memory usage: 48189 kb Process''s physical memory usage: 48197 kb 3 Process''s physical memory usage: 48377 kb Process''s physical memory usage: 48377 kb 4 Process''s physical memory usage: 48410 kb Process''s physical memory usage: 48410 kb 5 Process''s physical memory usage: 48541 kb Process''s physical memory usage: 48541 kb 6 Process''s physical memory usage: 48541 kb Process''s physical memory usage: 48541 kb 7 Process''s physical memory usage: 48541 kb Process''s physical memory usage: 48541 kb 8 Process''s physical memory usage: 48545 kb Process''s physical memory usage: 48545 kb 9 Process''s physical memory usage: 48549 kb Process''s physical memory usage: 48549 kb 10 Process''s physical memory usage: 48152 kb Process''s physical memory usage: 48152 kb 11 Process''s physical memory usage: 48500 kb Process''s physical memory usage: 48500 kb 12 Process''s physical memory usage: 48029 kb Process''s

So you’re telling me before refreshing my grid I have to reset/dispose the grid. I have to refresh my grid a lot and number of rows and columns will be changing on each refresh. So I reset/dispose the grid then user would see a blank screen while refreshing. It is really hard for me to justify this to my boss if we don’t reset/refresh the grid on each refresh then there is a chance that it might eat some memory. Just to mention I will not be using GBDG for my grid. Do you think GridControl also behave the same way. Please help me.

I do not think you have to recreate the grid each time. I do not think there are any leaks in the GridDataBoundGrid. Attached is a simple test project. The project has two forms that perform essentially the same task - populate a DataTable 100 times with 20K rows, clearing the rows from the DataTable between each pass. The first form does this with no Syncfusion code in it, just working directly with the DataTable. The second form has exactly the same code as the first except the addition of a GridDataBoundGrid and setting the Datatable to be the DataSource of the grid. If you run the sample, click the No Grid button, a form with a button on it will appear. Clicking the button will start the test. Afterwards, you can click the GridDataBoundGrid button on the initial form to perform the second test. If you compare the memory numbers shown in the textboxes, you will see the memory usage pattern is consistent with or without the syncfusion code. As far as your flashing concerns, the sample shows the use of grid.BeginUpdate/grid.EndUpdate to prevent this from happening. And the sample does not flash when the DataTable is cleared. In a virtual grid, you manage the data yourself, and the grid only interacts with it through its virtual events. So, as long as you handle the data efficiently, there should be no leaks. But I expect the memory usage will vary. For example, if you use a DataTable as a virtual grid''s datasource, the test on the first form in the sample shows the memory usage in the datatable can vary even though you are repopulating with the same data. GDBG_3017.zip

Thanks clay, I really appreciate for putting your time and efforts. The way you were patient and was replying all of my questions was really remarkable. Thanks again!