.

Can LINQ cause memory leaks?

Searches related to linq memory leak

• sql memory leak
• memory leak c# net
• msdn memory leak
• asp net memory leak
• wpf memory leak
• memory leak profiler
• tracking memory leaks
• linq sql memory leak

Research

• My experience 6/2010: Noticed in WikipediaToConfluence application: Written with background threads creating their own SQLMetal generated DataContext, and recreating a new DataContext every hundred records or so. Even without ever increasing memory usage, the Windows Vista system eventually gets very slow, and appears to run out of resources. Things like menus can not be selected in Visual Studio, other things requiring memory allocations fail, eventhough the system says it has 1-2GB of free ram after extended runtime of the application.
• Linq to SQL Pitfalls - link
  • Linq not designed to be used as Static Data Contexts
  • Multiple developers, multiple connectionstrings - creating datacontexts in code and specify a connectionstring for it as a parameter for the constructor. This controls the connectionstring setting at runtime and prevents unexplainable errors from occurring.
  • Deferred loading - You can prevent deferred loading problems completely when you do not expose types generated through a DBML in your service. Take the extra time for mapping code and writing data contracts, eliminates this problem
  • Merging your DBML - The DBML file is an XML file describing the mapping between your database and the generated C# code. - Lock it to avoid casting problems caused by merges.
  • Stored procedures versus LINQ queries - Stored procedures are still very useful. Stored procedures are way better at complex queries and you almost never need C# to perform that complex query you are writing.
  • Conclusion - Programming hasn't become any easier with Linq to SQL, there is still a lot to think about when working with this new technology and some things have become even harder than ever before. On the other hand, you have your data-access organised in no time, so you have more time to think about the hard parts like deferred loading entities and writing complex business logic. - My note: I was thinking the same thing that with all the great new programming tools and advances, there are still tons of little gotchas to worry about.

• link
  • Cause of memory leaks in .NET - references that keep the instances from being garbage collected.
  • DataContext does not maintain any static/global data so eventually the GC will free up anything it does create. The mapping information can be cached by storing it in a static/global variable.
  • memory leak exist with LinQ when using the "Refresh" method. I used it because my service always needs fresh data up to date with the database. And we know that LinQ return only memory data if it had them already read.
• memory used by a LINQ DataContext not being released even after I call context.SubmitChanges(). Workarounds include: only pull back 100 records at time, or create several contexts and have them all do separate tasks. If I keep the same DataContext and use it later for other calls, it just eats up more and more memory. Even if I call Clear() on the "var tableRows" array that the query returns to me, set it to null, and call SYstem.GC.Collect() - it still doesn't release the memory. link

  • DataContext tracks all the objects it ever fetched. It won't release this until it is disposed. This is the right way to go: using(DataContext myDC = new DataContext) { // Do stuff } //DataContext is disposed

  • Don't be afraid of creating a ton of DataContexts. They are designed to be used that way.
  • Questions about having DataContext in using block, and lots of memory is still used: http://www.c-sharpcorner.com/forums/ShowMessages.aspx?ThreadID=60849 - closing and disposing the data context (DataContext.Connection.Close()/.Dispose()), but even that doesn't seem to make any difference, and after 24 hours my little app is up to hundreds of MB of RAM. creating LINQ instances in "using" blocks, and am also requesting garbage collection (GC.Collect() to no avail. - No answers

• The LINQ to XML stuff is like XDocument... the entire file is consumed into memory.

Articles about general issue of memory leaks in .NET managed code

• Blog post - Rico Mariani has written a step-by-step guide to accessing the memory usage of a managed .NET - http://www.theserverside.net/blogs/showblog.tss?id=TrackingMemoryLeaks
• Sometimes you might be looking for why A is leaking. But you actually end up finding that since B was holding reference to A and B was leaking and thus A was leaking as well - Article on memory leaks with workflow fonudation and delegates - link
  • Delegates that aren't released can leak memory by holding references to instance objects
    • Basically, the principle theory is – if you are referencing some outside object from an anonymous delegate, make sure that object is not holding reference to the delegate in some way, may be directly or may be via some child objects of its own. Because then you have a circular reference. If possible, do not try to access objects e.g. instance inside an anonymous delegate that is declared outside the delegate. Try accessing instrinsic data types like int, string, DateTime, Guid etc which are not reference type variables. So, instead of referencing to an object, you should declare local variables e.g. instanceId that gets the value of properties (e.g. instance.InstanceId) from the object and then use those local variables inside the anonymous delegate.

    • Example of circular memory reference If any variable, whether parameter or local variable inside anonymous delegate is holding reference to something outside the anonymous delegate then we get a circular reference. someControl.OnClick += (sender, args ) => { someControl.Visible = false; } Here we have a circular reference. someControl is holding reference to a .NET compiler generated internal class which represents the anonymous delegate. And than class is holding reference back to the someControl. Thus none gets garbage collected.