Hi
I'm trying to understand some memory problems with my app and I need a basic understanding of how wingrid manages memory.
I have a button which executes a SQL query and returns a DataSet. The DataSet obviously owns an amount of memory
I then bind the DS to the grid using:
ultraGrid1.SetDataBinding( null, null ); ultraGrid1.SetDataBinding( oDS, null );
Q1: Does wingrid copy all of the data from the DataSet into the grid? Is my original DS unchanged?
Q2: If I press the button a 2nd time to repeat I will get a 2nd DataSet. Is my original DS still in memory? Does it go out of memory when ultraGrid1.SetDataBinding( null, null ); is called?
If I look at the app using Task Manager the memory just keeps going up until I get an out of memory exception
Thanks
I have run a memory profiler against my app. Each time I refresh the grid (with a new dataset) lots of UltraGridColumn objects are being left in memory. The thing keeping them in memory is the UltraGridFilterUIProvider in my main form.
The code was all put there by the Designer:
private Infragistics.Win.SupportDialogs.FilterUIProvider.UltraGridFilterUIProvider ultraGridFilterUIProvider1;
this.ultraGridFilterUIProvider1 = new Infragistics.Win.SupportDialogs.FilterUIProvider.UltraGridFilterUIProvider(this.components);
this.ultraGrid1.DisplayLayout.Override.FilterUIProvider = this.ultraGridFilterUIProvider1;
Any ideas? With a large amount of data I can only refresh the grid twice before the app crashes.
Could the fact that I cache the DisplayLayout cause the problem?
Regards
Hi,
Thank you for the replies.
I have attached a 14.1 version of my test sample, I have also modified it with the code that copies the layout.
Even after adding the layout code, it still works properly and memory usage doesn’t increase after changing the data source 100 times. Note that the GC.WaitForPendingFinalizers() and GC.Collect() calls are to reduce the wait for the garbage collector. The application should use the same memory without them once the garbage collector decides to collect the memory, but that can happen after some time.
If the memory increases for you, then something must be still referencing the old data source and thus the garbage collector can’t free that memory. Please modify my sample so it reproduces this issue and I will be glad to investigate it further.
I am looking forward to hearing from you.
Any chance of a copy of that test project with 14.1?
The app has a single wingrid whose contents vary depending on a toolbar button. e.g. the same grid is used to display a list of equipment, jobs, spare parts etc. The grid layout is different for each.
oLayout = new UltraGridLayout(); oLayout.CopyFrom( ultraGrid1.DisplayLayout );
oDS = GetSomeData();
ultraGrid1.SetDataBinding( null, null );
ultraGrid1.SetDataBinding( oDS, null );
Then I call:
ultraGrid1.DisplayLayout.CopyFrom( oLayout );
Could that cause the data to be held on to?
Thanks for your help. In my application I can potentially have a grid with 200,00 rows with 200 columns. After filling the grid once the Task Manager shows a working set size of 500M. If I re-run the query, the memory usage never goes down but ends up at 900M. If I do it again it goes up to 1.2G. After a few more goes it bombs with an out of memory exception. My code basically looks like yours.
I used to do GC.Collect & GC.WaitForPendingFinalizers between each refresh, but with Windows 7, as soon as GC.WaitForPendingFinalizers is called alled of the grid hidden columns are briefly unhidden, and then re-hidden when the call completes. I took it out because it scares the users. It doesn't make any difference to the memory usage if I leave it in.
If I fetch a smaller amount of data the memory doesn't go down. It's only when I close the form that the memory seems to be released.
Should I be looking in places like InitializeRow and IntialiseLayout for problems?