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: memory management  (Read 9351 times)
quinrou
Jr. Member
**
Posts: 18


View Profile Email
« on: July 10, 2007, 03:34:53 »

Hi,

I have been looking at the 3 following frameworks PureMVC, ARP3 and Cairngorm 2.01.  And what stricked me the most in PureMVC (as well as ARP3) is that everything get stored in Arrays (views, commands...). So from my understanding since none of the instance classes will have weak references they will never be up for being garbage collected. This will just keep making the memory usage go up, won't it? and eventually make the computer crash.

Wouldn't it be more appropriate to use dictionaries ( new Dictionary( true ) ) to store the instances instead of arrays (new Array() )?

What do you think?

thanks
Seb
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 11, 2007, 08:26:29 »

Seb,

One of the early decisions made in the PureMVC Requirements was that it would be implemented in pure ActionScript and not rely upon any Flex or Flash classes. Dictionary is flash.utils.Dictionary, and was therefore off limits for the implementation.

However, this doesn't mean that zombie objects will ultimately overpower your machine. There are several reasons for this.

Firstly the Flash player uses a combination of two garbage collection methods: Reference Counting, and Mark and Sweep. In reference counting when the number of objects holding a reference to the object drops to zero it is available for collection. However this doesn't always get rid of everything that *should* go. You could have two objects that should be collected, since nothing else points to them, but they point to each other, and thus keep each other's ref count from hitting zero. Mark and sweep comes in and cleans these dust bunnies up.

Secondly, and more importantly, the use of arrays inside the framework is generally static with very little change after application startup. Why?

1) Because your Command mappings generally don't change dynamically. They represent your application's Use Cases. How often do the Use Cases for an application change at runtime? It can be hard enough to get them pinned down at requirements gathering time... :)

2) Proxies are almost always initialized at startup (even if they delay the instantiation of their data objects until accessed), and do not change.

3) The primary Mediators for the application are usually initialized at startup as well. Occasionally a Mediator's creation will be deferred until the user navigates to View Component that has had its instantiation deferred. But once instantiated, the View Component and the Mediator usually need to hang around for the rest of the application runtime.  If the View Component is transient, like a popup, then usually one Mediator is instantiated to handle it and it deals with creating and destroying the popup.

So, the upshot of 1, 2, and 3 is that even if GC failed us, PureMVC's array usage patterns don't lend themselves to runaway object buildup syndrome.
Logged
quinrou
Jr. Member
**
Posts: 18


View Profile Email
« Reply #2 on: July 16, 2007, 07:08:04 »

Cliff,

thanks for the reply. I now undersand why you didn't use Dictionary since it relies on the Flash library and that you wanted to keep the Framework purely AS3.

I have quick question though what would happen if I was loading in a screen/pugin at runtime that would add its own commands and also create its own Mediator. These wouldn't be collected once done with them, or would they thanks to reference counting?

thanks
Seb
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: July 16, 2007, 07:22:51 »

Seb,

You'd just want to use removeCommand and removeMediator when you are done. Note that removeCommand is not on the IFacade interface, it's not something you'll do a lot. You can implement it on your ApplicationFacade, though, and still not have to make a call to the Controller.

-=Cliff>
Logged
Pages: [1]
Print