Memory leak

 

As I demonstrate below, memory is recovered when you clear the EntityManager. It would be recovered if you disposed of the EntityManager itself.  I'm not sure why you didn't see these effects. 

However, you are absolutely right that something horrible is happening. I spent much of the day researching it.

 

The only good part of the story is that it has nothing to do with DevForce. The cause is something in Silverlight, probably in the Silverlight DataGrid.

 

I will explain but it will be a bit of a journey leading ... ultimately ... to a sad-but-necessary workaround.

 

If you want to skip the journey and go right to the destination, the lesson for your code is:

 

 

And now ... my sad tale ...

 

The main "ModelExplorer" view binds a Silverlight DataGrid.ItemsSource to the QueryResults property of the supporting ModelExplorerViewModel (the VM).

 

"QueryResults" is defined as IList but is always an ObservableCollection<T> in practice (henceforth written as "OC<T>").

 

The problem starts with the repeated resetting of the QueryResults in the ModelExplorerViewModel after every query.

 

A peculiarity of PrismExplorer (PE) is that the main "ModelExplorer" view could be asked to display objects of any type in the DataGrid. That's its purpose as a demo screen. Your grids typically only show one kind of object. But PE must work with arbitrary query result types.

 

Because those types change, the OC<T> must change to match type.

 

The obvious thing to do was craft a new OC<T> after every query ... one designed for the query results type, assign that new OC to the QueryResults, and raise PropertyChanged on "QueryResults". The DataGrid dutifully hears the call and refreshes its display.

 

Unfortunately, it consumes an extra 300K every single time. "300K" is not a misprint.

 

Here's the code with the garbage collection call and logging (aside: we now inject ILoggerFacade into the VM now so that we can write to the Visual Studio Output window).

    public IList QueryResults {
      get { return _queryResults; }
      set {
        _queryResults = value;

        Log("=== Total Memory = " + GC.GetTotalMemory(true));

        RaisePropertyChanged("QueryResults", "QueryResultsCount");
        SelectFirstQueryResultsItem();
      }
    }

If you add this instrumentation, query for "All Customers", and click the "Query" button repeatedly, the Output window will show that your memory consumption is climbing ~300K each time.  Here are actual measurement.

Note that DevForce isn't going anywhere. You are issuing the same query repeatedly and DevForce satisfies it from the EntityManager cache. However, the PE ViewModel is building a new OC<Customer> each time and reassigning QueryResults. The DataGrid is rebinding the ItemsSource to the new OC<Customer> each time ... and chewing up memory each time.

 

If we comment out "_queryResult = value", DevForce and PE will continue to do their things ...  DevForce may query the database or satisfy from cache if it can. PE will always build a new OC<T>, assign QueryResults with that OC<T>, raise PropertyChanged, stimulate the DataGrid to rebind to the QueryResults. Exactly the same code paths.

 

The only programmatic difference is that QueryResults always returns the exact same (empty) object.

 

The memory consumption goes flat ... as it should.

 

Of course it climbs everytime you issue a query that fetches new data; that is to be expected. Press "Clear" to clear the EntityManager cache and memory is recovered.

 

• clear the _queryResults ( _queryResults.Clear() ) before re-assigning it with the new OC
• clear the _queryResults and set it null before re-assigning it with the new OC
• clear the _queryResults, set it null, raise PropertyChanged ... then assign with new OC

 Here are memory reports:

 

 // Query for All Customers
 Prism Explorer: "=== Total Memory = 3411896"
 Prism Explorer: "=== Total Memory = 3425356"
 Prism Explorer: "=== Total Memory = 3416064"
 Prism Explorer: "=== Total Memory = 3416076"
 Prism Explorer: "=== Total Memory = 3416076"
 Prism Explorer: "=== Total Memory = 3429460"
 Prism Explorer: "=== Total Memory = 3416076"
 Prism Explorer: "=== Total Memory = 3415020"
 // All Employees
 Prism Explorer: "=== Total Memory = 4203344"
 Prism Explorer: "=== Total Memory = 4212964"
 Prism Explorer: "=== Total Memory = 4213000"
 Prism Explorer: "=== Total Memory = 4213000"
 Prism Explorer: "=== Total Memory = 4213000"
 // Clear Entity Cache ... followed by All Employees
 Prism Explorer: "=== Total Memory = 3706416"
 Prism Explorer: "=== Total Memory = 3588660"
 Prism Explorer: "=== Total Memory = 3593996"
 // First Employee
 Prism Explorer: "=== Total Memory = 3590928"
 Prism Explorer: "=== Total Memory = 3604372"
 Prism Explorer: "=== Total Memory = 3589676"
 // Employees named Smith (there are none)
 Prism Explorer: "=== Total Memory = 3605584"

 Prism Explorer: "=== Total Memory = 3757472"
 Prism Explorer: "=== Total Memory = 3762120"
 Prism Explorer: "=== Total Memory = 3770336"
 Prism Explorer: "=== Total Memory = 3762144"

 

It kept me busy for weeks and exhausted me quite a bit, for I'm new to most of the technologies. However it still is very promising to me especially with the (more than) starter kit 'Prism Explorer' is. For now I'll try this temporary work around (also for learning excitement) and maybe I'll focus on getting PRISM 4 RTC to work for me.

 

The forum the anonymous poster mentioned was my source for the DataTemplate issue, if I had know this was the source for the problem I presented I would have given you the link, sorry. (your link 'link in the silverlightForum' in this post misses this at the end: .aspx#387384)

 

I'll keep a close I on Tim Heuer's twitter.

 

thanks and best regards,

Niels

 

Hi Ward,

The DataTemplate bug has been fixed by the Silverlight Team in the september 2010 service release:

And I can confirm :-)

Best wishes,

Niels