Er, this isn't strictly correct.
The module (the SWF and the class factory it contains) are only ever
loaded/instantiated once, ever, no matter how many times you call
"load".
ModuleLoader, on the other hand, creates -instances- using the module's
class factory, and adds them as a child. These instances don't always
get fully cleaned up for GC (there certainly is no guarantee that
they'll get recycled immediately, but there are also occasionally some
references in the frameworks that don't always get unhooked correctly..
this is an active area of cleanup in the frameworks code).
I suggest that you play with the low-level ModuleManager/IModuleInfo API
to get a feel for the memory behavior of modules outside of the context
of modules that use the frameworks, and then work your way back to using
ModuleLoader to load frameworks components.
Cheers,
-rg
________________________________
From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Fabio Terracini
Sent: Tuesday, March 06, 2007 7:06 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Flex Player 9's (Flex 2) Memory Usage
- What's Normal?
Speaking on Modules, I might suggest you an hybrid approach.
If you load ModuleA, then load ModuleB and load ModuleA again
(either
by ModuleLoader or by SWFLoader), you'll end with two ModuleA
loaded
up into memory - you can confirm this by placing a Timer to
output a
trace (it's really hard to really remove a displayObject from
memory).
If you use ViewStack instead, you'll only have that ModuleA
loaded
once - but ViewStack implies on downloading all the Module at
the same
time - no progressive download at all.
So, the hybrid approach is something that I call
"StackedModules".
I've blogged about
(http://blog.dclick.com.br/2007/01/23/gerenciamento-de-memoria-e-tamanho
-dos-arquivos-em-grandes-aplicativos-utilizando-o-modules-do-flex-201/
<http://blog.dclick.com.br/2007/01/23/gerenciamento-de-memoria-e-tamanho
-dos-arquivos-em-grandes-aplicativos-utilizando-o-modules-do-flex-201/>
)
but it's in Portuguese so you might just check the performance
charts
(or Google Translate it ;-)). At first sight it's simples as:
<mx:ViewStack>
<mx:ModuleLoader />
<mx:ModuleLoader />
</mx:ViewStack>
You might improve by using ModuleManager.getModule() to check if
the
Module is loaded, then load if necessary, or just change the
selectedIndex, and so on. And build it using dynamic linking
(either
external or RSLs).
[]s
Fabio Terracini
On 3/5/07, jeofmoyster <[EMAIL PROTECTED] <mailto:jeof%40jeof.net> >
wrote:
> So I'm developing what will be a good-sized application, but
I'll be
> carefully planning for download speed and runtime efficiency
through
> ModuleLoader, SWFLoader, etc.
>
> Right now I've barely begun but have finished the ground level
for the
> Data Retrieval, Normalization and Management (no FDS). The
memory
> monitor object shows about 40 megabytes of memory being used
when the
> data comes in, and drops to 24 MB if I leave the app still for
a a
> couple minutes afterward (I assume that's garbage collection
kicking
> after the data normalization).
>
> Flex is one my first forays into needing to worry about things
like
> memory management, so I'm looking for best practice and a
baseline of
> what's expected and acceptable.
>
> 1) What's "average" memory load for a Flex application? When
do I
> start freaking out about using too much memory?
>
> 2) How do I optimize memory management during run time? What's
the
> best way to encourage good garbage collection?
>
> Ideally this app will cache the data it receives over the
course of
> its runtime so switching back to older sets is faster than
reloading
> it from the server, but if this seriously chokes memory, I
need to
> come up with a new strategy.
>
> Any help is appreciated!
>
>
>
>
>
> --
> Flexcoders Mailing List
> FAQ:
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
<http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
> Search Archives:
http://www.mail-archive.com/flexcoders%40yahoogroups.com
<http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> Yahoo! Groups Links
>
>
>
>
