0

I am monitoring the consumption of my software's memory through dotMemory JetBrains.

I noticed that when I do a query through my repository, then if I close the window, I have left the object from which I made the call; my repository into memory, I used using and even dispose of my context but nothing remains .. in memory. What can I check?

Here is the offending code:

LoginViewModel.cs

using (DbContext = new Context())
{
   var creazioneDocumentoRepository = new RepositoryBase<CreazioneDocumento>(ctx);
   var creazioneDocumento = creazioneDocumentoRepository.Lista();

   if (creazioneDocumento == null || creazioneDocumento.Count == 0) 
      return;

   var decimaliQuantita = creazioneDocumento.Max(x => x.NumeroDecimaliQuantita);
   _NumeroDecimaliQuantita = decimaliQuantita != 0 && decimaliQuantita > 0 ? decimaliQuantita : 0;

   var decimaliPrezzo = creazioneDocumento.Max(x => x.NumeroDecimaliPrezzo);
   _NumeroDecimaliPrezzo = decimaliPrezzo != 0 && decimaliPrezzo > 0 ? decimaliPrezzo : 3;
   _NumeroDecimaliImponibile = 2;

   //   ctx.Dispose();
}

Doing debugging, I noticed that up to:

if (creazioneDocumento == null || creazioneDocumento.Count == 0) return;

the object is not remembered, but as soon as I run the "max" the object remains in memory.

Here is a screen shot from dotmemory:

enter image description here

Instead this screenshot tells me what are the methods that reference and keep in memory my loginviewmodel and I believe they are the two max:

enter image description here

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Brux88
  • 138
  • 4
  • 17
  • You are aware that you have NOT proven a memory leak in a GC environment? All you did prove is that objects that are not garbage collected YET are not out of memory YET. You miss the proof of the GC running before taking the second measurement. Voting to close - can not be reproed. – TomTom Apr 02 '16 at 09:29
  • @TomTom When dotMemory get snapshots it performs full garbage collection, hence if there are objects in memory it means they are held by some roots. Brux88: I see that not an instance of LoginViewModel itself, but an instance of some lambda with closure is held in memory by some other delegates. It's impossible to say something more w/o LoginViewModel class source code. – Ed Pavlov Apr 02 '16 at 15:29
  • In fact, as I thought. but I do not understand how to free up memory. the problem is when I execute this line: var decimaliQuantita = creazioneDocumento.Max(x => x.NumeroDecimaliQuantita); ..... how i can fix? – Brux88 Apr 02 '16 at 16:07
  • reading on the internet, I found this article: http://blog.jetbrains.com/dotnet/2014/07/24/unusual-ways-of-boosting-up-app-performance-lambdas-and-linqs/ so I think the problem expression lambda wing, it is retained in memory. it's correct? I use lots of lambda expression, how can I solve? daverro has a problem keeping all of these in-memory objects using lambda? – Brux88 Apr 04 '16 at 14:02

1 Answers1

0

.NET CLR is a managed, garbage-collected runtime/virtual machine.

You can't expect that objects will be reclaimed and removed from memory as soon as they're not necessary.

In the other hand, IDisposable.Dispose is just an interface method to define code to release underlying resources used by the implementation: it's not a built-in method to release memory.

The garbage collector (GC) reclaims memory as a background process and it won't remove anything instantly, but based on assumptions overtime.

Further reading: Understanding garbage collection in .NET

Community
  • 1
  • 1
Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
  • In addition, with IDisposable.Dispose you should be sure that unmanaged resources are released. BUT in your case you have a connection to a DBMS that are pooled so the connection and related resources won't be released. For managed objects if you run a stress test and profile the memory you probably will see a sawtooth shape. – bubi Apr 02 '16 at 08:20
  • memory profiler performs full garbage collection in order to obtain a memory snapshot – Ed Pavlov Apr 02 '16 at 15:32