Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Avoiding Memory Leaks?  (Read 3649 times)
pajhonka
Newbie
*
Posts: 6


View Profile Email
« on: December 22, 2010, 01:38:19 »

Hi,
I have an AIR application that is comprised of four different views. The Stage Mediator has a timer that fires the 'animate in' and 'animate out' functions of each. The model is comprised of some unique and some shared data. For example, the first state of the application displays the visitors checked into a facility. This checked-in visitor info is necessary for all other views.

Currently, the application has several leaks. It starts with a memory consumption of 70K which builds to 500K after an hour. Here are some methods that I think might be causing the leaks:

  • In mediators and proxies that depend on shared information, I am instantiating the proxy that populates the appropriate VO. Can I create some kind of global application-wide variables without having to do this?
  • How does facade.retrieveProxy work with regards to memory?
  • I'm not sure what the best practice is for garbage collection and PureMVC. The proxies pull data from the web and a database, so each time they cycle in, they need to have updated information. I was going to set the data and views to null after each 'animate out,' but maybe there's a better way?

Sorry if these questions are hard to understand. If not specific to my issues, I'd still like to hear some of the best practices for avoiding memory leaks with PureMVC.  Thanks!
« Last Edit: December 22, 2010, 01:45:55 by pajhonka » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: December 23, 2010, 08:53:16 »

In mediators and proxies that depend on shared information, I am instantiating the proxy that populates the appropriate VO.
Don't instantiate the Proxy in the Mediator, instantiate and register it at startup time in a Command and then retrieve the reference to it from your Mediator. There should typically only be the one instance of a given Proxy.

Can I create some kind of global application-wide variables without having to do this?
Global variables are what you want to avoid. They lead to spaghetti code or Shantytowns.[1] If everything can access anything then eventually it will. By separating things into tiers and defining the communication amongst those tiers, you are able to keep the borders (model and view) of your application reusable. In the example above, the registered Proxy is available to all the actors that need it; it can be retrieved at any time from any Mediator, Command or other Proxy using facade.retrieveProxy. Your view components don't have access to the Facade and thus to this Proxy, but they don't need it. They should not be aware of the PureMVC apparatus, but instead be 'spoonfed' their data by Mediators.

How does facade.retrieveProxy work with regards to memory?
It retrieves a reference to the registered instance of the Proxy by the given name. Again, there should typically be only one instance of a Proxy registered, and thus ever instantiated.

I'm not sure what the best practice is for garbage collection and PureMVC. The proxies pull data from the web and a database, so each time they cycle in, they need to have updated information. I was going to set the data and views to null after each 'animate out,' but maybe there's a better way?

If the Proxy has a collection of VOs that have been sent to the view components and that collection is replaced by the result of another service call, then the Proxy will no longer be holding any references. If that original collection had been sent to a Mediator by way of a notification, and the Mediator simply set the collection onto its view component without keeping a reference for itself for any reason, then when the whole cycle is repeated, the old collection and all its contents will be GC'd if you haven't made any further references to the collection or the contents. If you have, then yes you might want to add a method to your view components called something like resetView() that Mediators call when they receive notification of new data from the Proxies. They could call resetView(), which would null any 'currentSelection' type properties you may have defined in the component. Then you could set the new data on the component and pretty much be sure that the references are taken care of.

You don't need to worry that PureMVC internally is hanging on to your data or building up all sorts of objects you don't need. The only hidden objects it creates are Observer instances that are used to route notifications to the Controller for launching Commands and to the Mediators for their registered interests. Everything else is objects you create and can easily keep track of and manage as you would in any AS3 program.

-=Cliff>

[1]
http://www.laputan.org/mud/mud.html#BigBallOfMud
Logged
pajhonka
Newbie
*
Posts: 6


View Profile Email
« Reply #2 on: December 23, 2010, 04:20:14 »

I've set up my applications with your suggestions. Thank you, Cliff.
Logged
Pages: [1]
Print