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 Usage and Multi-core  (Read 6480 times)
jgervin
Courseware Beta
Sr. Member
***
Posts: 50


View Profile Email
« on: June 29, 2009, 08:49:15 »

So my app is up in beta, but now I get to do a major rewrite....maybe.

So I have an app, built on Single version of PureMVC, which can be extremely processor intensive. I let the user switch between two views, possibly five views in the future. When the user switches between the two views I remove all the proxies, mediators, etc... and build the new view from scratch. So I was thinking about moving to multicore to allow for a document based application so the user can have tabs open (like Firefox) and switch between views.

The question I have is, since a single view right now can eat up memory and cpu, would using modules and multicore in a document based app be ok or would it kill the CPU and eat more memory?  I would think if I put the views in a tab navigator it the views that aren't being shown wouldn't eat up as much memory if they aren't being rendered and not animation or data processing is going on in those views, right?

Are modules the best way to go here? Maybe it would be better to create new view objects in a tab navigator, rather than modules with view objects in each tab navigator? Honestly, I hate dealing with modules, but if it will give the best performance then so be it.

Maybe sticking with what I have would be the best way, given the processor and mem usage of the app?


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



View Profile WWW Email
« Reply #1 on: June 29, 2009, 12:56:12 »

If you use the Flex ModuleLoader to handle loading/unloading of modules, you can manage it just fine.


However, recently I've had difficulties with garbage collection of modules instantiated directly as Flex components. Early on I thought I had it whipped, but then the desire to do Flex binding across modules in the view hierarchy got the best of me, and I find Flex is hanging on to objects no matter how thorough I am with removal of listeners and removeChild called on those children in the view.

I've been trying this approach as a more Flex-friendly approach, and found it easier to implement than pipes or interfaces.

But it appears better to have modules be loaded, plumbed and communicated with in that fashion. The plumbing can seem like a hassle to put in place, but in the end, it's possible to reclaim all the memory and be fully in control.

Check out Simon's great post on garbage collection with MultiCore:
http://www.nutrixinteractive.com/blog/?p=132

-=Cliff>
Logged
jgervin
Courseware Beta
Sr. Member
***
Posts: 50


View Profile Email
« Reply #2 on: June 29, 2009, 01:13:48 »

thx
Logged
Pages: [1]
Print