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
gstanbury said:Q1: Does wingrid copy all of the data from the DataSet into the grid? Is my original DS unchanged?
No, and yes. The grid doesn'y create any kind of copy of the data, although the grid does create structures of it's own that will mirror the data source. For example, the grid will create bands and columns to represent the tables and fields in the data source. For the data itself, the grid will often request the data value of a particular field and put that data into a UIElement to display as a string or image, etc.
The Datasource is not change in any way at this point (assuming you haven't changed any of the cells in the grid). But the DotNet framework will create a BindingManager to help communicate between data source and the grid and maintain the current position.
gstanbury said: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?
Pressing this button a second time will disconnect the grid from the DataSet and then reconnect it. No new DataSet is created (since you are still referencing the same oDS variable). Your original DataSet is still in memory (assuming nothing in your other code outside of this button disposed it).
If the memory is increasing every time you do this, then it's possible it's a memory leak in the grid, or the BindingManager or in some other part of your code like one of the grid's event handlers.
Thanbks for your quick reply.
The DataSet is new each time.
So, when I call:
DataSet oDS = GetMeSomeData()
ultraGrid1.SetDataBinding( null, null )
ultraGrid1.SetDataBinding( oDS, null )
is my original DataSet still in existence?
I'm not familiar with the BindingManager (even though I have used Wingrid for years). Is this something that I have to get rid of?
Hello,
Thank you for contacting Infragistics Developer Support.
The BindingManager is responsible for the synchronization of data-bound controls on a Windows Form. You shouldn’t remove it as it is vital part of how data binding in WinForms works. Here is a link to the MSDN BindingManager article:
http://msdn.microsoft.com/en-us/library/system.windows.forms.bindingmanagerbase(v=vs.110).aspx
As for your other concern, I created a small test using the code snipped you provided. In my test I repeatedly create a data source and add a table to it with 20 columns and 10000 rows. After doing that a 100 times and forcing the GC to collect the unreferenced objects the used memory basically remains the same. So I don’t believe that resetting the data source the way you do it will cause memory leaks.
I have attached my test sample for your reference.
Please let me know if you have any additional questions.
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?
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?
Any chance of a copy of that test project with 14.1?
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.
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 Dimitar
Thanks very much for the sample. I will keep playing with this until I can reproduce the behaviour that I am seeing with my app. If I can then I will get back to you. Apart from using lots of caches (generally HashTables) and having many different screens and cached layouts/DataSets, in principle the sample you have sent should allow me to do that.
I'm fairly certain that it relates to Excel filtering in some way. If I repeat the same search multiple times then I end up with an arbitrary number of DataSets left in memory and they are always being held there because of FilterUI objects
Thanks for your help