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

And I can confirm :-)

Best wishes,

Niels

 

Unhooking from EventAggregator, for example, shouldn't be necessary unless you explicitly defeated its default weakly referenced handlers.

 

Rarely hurts to be careful.

 

We are eager to open a "Good Practices" section of the Wiki ... and your findings would be welcome there when we do.

 

Happy coding!

Hi Ward,

 

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

 

 

---

Thanks, Anonymous, ... nice find!

That link in the SilverlightForum (http://forums.silverlight.net/forums/p/171739/387384.aspx#387384 ) aligns well with the scenario presented here. The autogenerating DataGrid is likely creating DataTemplates on the fly ("inline") and triggering this unwanted defect.

Looks like the root-cause will affect all controls, including 3rd party controls.

Tim Heuer writes in his July 30 comments "Right now we have a plan [for releasing a service pack that includes a fix to the DataTemplate leak problem] and are driving toward that plan which I've mentioned here as [expected] before end of Summer."

We'll just have to be patient.

 

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.

 

    public IList QueryResults {
      get { return _queryResults; }
      set {
 
        ResetQueryResults(value);
 
        Log("=== Total Memory = " + GC.GetTotalMemory(true));
 
        RaisePropertyChanged("QueryResults", "QueryResultsCount");
        SelectFirstQueryResultsItem();
      }
    }
 

    private void ResetQueryResults(IList results) {
 
      if (null != _queryResults) _queryResults.Clear();
      if (null == results || 0 == results.Count) return;
 
      var resultsType = TypeHelper.GetItemType(results);
 
      if (_queryResultsElementType == resultsType) {
        // Same results collection type; can refill it
        foreach (var item in results) {
          _queryResults.Add(item);
        }
      } else {
        _queryResults = results;
        _queryResultsElementType = resultsType;
      }
    }
 
    private Type _queryResultsElementType;

 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"

This last year I've been trying to get DevForce 2010 and Silverlight 4 to work for me, which I bought a year ago (Devforce Universal). But everytime I stumble upon things that don't work for me. Learning moments! Beside some bugs in Silverlight 4 for which work arounds have been presented, I'm now stuck al together with this:

When ever I bind a datagrid or listbox via a ViewModel to an ObservableCollection which has been build up by the TypeHelper.CreateObservableCollection(results) in a Callback method from a simple query (for example query=Manager.Artikel) and I refresh the records with a new call to the query, I end up consuming memory which will never be released, even not after disposing of the EntityManger, View, Viewmodel, etc. This behavior can be reproduced in your Prism Explorer when querying Customers, Orders, and back a few times. You can see this in Performance Monitor (perfmon) under process->private bytes  where the count keeps climbing up.

At first I (about a month ago) thought that had to do with 'the inline DataTemplate bug', but I have removed al these instances and it still exists.

Could someone please help me?

thanks

Niels