Click here to Skip to main content
15,888,816 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hi
I have an application that needs to frequently backup a dataset and revert to that backup if the users decides to cancel an action.
There is a global dataset created at the top of the class:
DataSet database = null;


Every time a form is opened the main dataset is copied into the created variable:
database = AppModel.Instance.Data.Data.Copy();

The problem is that every time the form is opened the memory increases by quite a lot and is never released.
I've tried disposing the database variable after it's been used but the memory still remains high - This has left me to believe that the DataSet.Copy() method allocates to new memory every time.

Any suggestions to free up the memory would be greatly appreciated.
Regards,
Jason
Posted
Updated 11-May-11 0:48am
v3

I don't get it. Let me see what you trying to do. When a user opens a new form, you copy the dataset so that you can have a copy in a case when and if the user changes his mind? right.

What I would do is that, instead of copying that chuck of data over and over again, utilize the build-in functionality to accept or to reject the changes as the user makes his mind

Look at DataSet.RejectChanges[^]

DataSet.AcceptChanges[^]
 
Share this answer
 
v3
Comments
Espen Harlinn 11-May-11 13:04pm    
Good point, my 5
Hi there,

If your working with C# and .net then you cannot force the garbage collector and thus disposing of the back-up dataset is pending....and so is your memory allocation.

Now if you have to backup frequently I suggest an embedded database and creating a backup routine according to your wishes... and thus not using more memory than needed.

And if you fine tune your backup routine to working with dataset.GetChanges(), the transaction wil be even faster..

And if you don't wanna have an embedded database all pre-made, why not add, create "scheme deffinitions" on the fly.

I hope this helped
grtz
 
Share this answer
 
Well you can request the Garbage collector to run garbage collection process by

GC.Collect();
GC.WaitForPendingFinalizers();

This doesn't guarentee the memory to be cleaned up immediately because of GC's own algo and flow plus this is not recommended because and garbage collection is a costly process as it has to check every thing marked as disposed and after cleaning up it re-position all in-memory objects sequally.

here is the link:
http://msdn.microsoft.com/en-us/library/system.gc.waitforpendingfinalizers.aspx[^]

Thanks,
Hemant
 
Share this answer
 
Comments
Dave Kreskowiak 11-May-11 10:37am    
Not a valid solution. This is more of an education issue and clearing up a misunderstanding of how memory management works in the .NET CLR.
Hemant__Sharma 11-May-11 10:39am    
"Any suggestions to free up the memory would be greatly appreciated" how will you answer this?
Dave Kreskowiak 11-May-11 10:57am    
You don't do anything! The memory isn't actually being used! It's sitting in a managed heap ready to be allocated for other objects that his app may use. Like I said, TaskManager is not accurate when it comes to looking at memory usage in .NET.

If Windows needs the memory for other things, the .NET CLR will happily return memory from the managed heap.
You're probably looking in Task Manager to see the memory usage of your application. DON'T!

.NET applications, like Java, run in a virtual execution environment. Task Manager is showing you the memory that is RESERVED for your applications environment, not how much your app is actually using.

Use PerfMon and the .NET Memory counters to see how much your app is actually using.

The .NET CLR maintains a managed heap of memory that it uses to allocate objects that your application creates. When you're no long using those objects, the memory gets returned back to the managed heap, not to Windows. Task Manager is showing you that size of that managed heap, among other things.

If Windows runs low on memory, the .NET CLR does a very good job of managing its heap and will return memory back to Windows whenever Windows wants it.
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900