My understanding of the Player's garbage collector/memory management is by
no means perfect (or even maybe accurate).  I believe the deal is:
- it does a real cleanup every minute or so
- memory is allocated and used in chunks, but is cleaned up in pieces
- the allocator is not super-smart, it does not re-organize memory within
individual chunks, so you can get fragmented and continue to grow if the
spaces in the chunks are not big enough for what needs to be allocated
- at some point the player may have a big enough chunk free that it can give
it back to the OS; but windows will not take it back (i may be wrong here,
the player may never offer it back).  therefore player memory will always go
up, it rarely goes back down.  however if you do your own de-allocation the
player should arrive at a steady state, it just is possible it will end up
looking like a big number in the task manager. 

HTH,
Matt

-----Original Message-----
From: Scott Barnes
To: flexcoders@yahoogroups.com
Sent: 3/31/2005 11:06 PM
Subject: Re: [flexcoders] Creation/Destroy Queries...

heh i was wondering what happened with that..but hello back none the
same ;)

Ok heres what my gameplan is in terms of why I asked those Questions:

I am going to have a XML situation where i Declare my Screens like this:

<screen name="xyz" template="com.path.to.base.mxml.file"
creationPolicy="auto"
presenter="com.path.to.screens.presenter/controller.as.file"
defaultEvent="mail.default">

      <events>
            <event-handler name="mail.default">
                  <filter name="securityCheck"/>
                  <filter name="loadProfile"/>

                  <listener name="mailService" method="getAllMail"
resultKey="mailModel"/>
                  <listener name="mailService"
method="getMailFromFolder"
resultKey="messagesModel">
                        <argument name="folderIndex" value="0"/>
                  </listener>

                  <view-pod name="mailTreePOD" sector="a"/>
                  <view-pod name="mailActionsPOD" sector="a"/>

            </event-handler>
      </events>

      <events>
            <event-handler name="mail.loadFolder">
                  <filter name="securityCheck"/>
                  <listener name="mailService" method="getAllMail"
resultKey="mailModel"/>
                  <listener name="mailService"
method="getMailFromFolder"
resultKey="messagesModel"/>
                  <view-pod name="messagesGrid" sector="b"/>
                  <view-pod name="messagesPreview" sector="c"/>

            </event-handler>
      </events>

</screen>

Now inside my template, I'll have panels and what not setup, then
inside those panels i may put in viewStacks or no children at all,
lots of base foundation stuff. Then inside the presenterClass it will
know whats inside itself and add various behaviours and follow a
uniform approach to how it presents stuff on screen.

Now, when a button is fired an event handler request is initiated,
resulting in an action. In this case, mail.loadFolder does like
outlook where if you clicked on a folder it would show all mail
relating to that folder and what not.

Now inside the base foundation I have sectors layed out and declared
via presenter, as my presenter maps to each of these sectors it
records whether or not these are viewstacks or not, if not it will
destroy/create a view-pod in that sector - if its a viewStack it will
check to make sure that child exists, if not instantiate that view-pod
or simply switch to it...

Now lots more can go on here but the point is this, i'm going to be
doing a lot of runtime create/destroy concepts and its very important
that i'm allowed to do so without memory considerations - plus any
performance gains i can conjure up in terms of asset re-use is even
better.

At the same time as view-pods being destroyed/created i can ontop of
that kill an entire screen and move onto another screen.......

Hopefully that paints a picture on what my intent is, and does anyone
here see any negative performance side-effects from this approach?




On Apr 1, 2005 4:48 PM, Abdul Qabiz <[EMAIL PROTECTED]> wrote:
> 
> Ignore attachment, my mistake placed there...
> 
> 
> -----Original Message-----
> From: Abdul Qabiz [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 01, 2005 12:14 PM
> To: flexcoders@yahoogroups.com
> Subject: RE: [flexcoders] Creation/Destroy Queries...
> 
> I take this one :)
> 
> > - mx:Model/XML if i place that inside a MXML component, on compile
> > time, does FLEX embed that said file inside the swf or does it
request
> > it be download once base assets have been initialized (I'm a bit
> > sketchy on this part). I'm sure its a RTFM situation but I must be
> > missing where that part is stated heh :)
> 
> Yes, Flex embeds the file into main SWF file at compile time. So your
main
> SWF contains all custom component code, Model/XML data.
> 
> -abdul
> 
> -----Original Message-----
> From: JesterXL [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 01, 2005 11:51 AM
> To: flexcoders@yahoogroups.com
> Subject: Re: [flexcoders] Creation/Destroy Queries...
> 
> I can take 3 of these.
> 
> - creating of components does not touch the server (for view controls
> anyway).  If you create a child, yeah, it'll ask for more memory if
none is
> researved already for you.  If you destroy a child, the way it worked
in the
> 
> past was removeal of the movie clip, and it deleted the reference.
You
> can't do anything more effectively or cleanly in Flash; at that point,
it's
> up to the Flash Player, and so far, it works fine.  However, just
because
> delete returns true doesn't really mean much; I have no clue if it
actually
> frees the memory, when GC runs, etc.
> 
> - from the docs: "Classes that descend from the UIObject class that do
not
> specify a creationPolicy property inherit their parent's
creationPolicy
> property."
> 
> - remote shared libraries, at least in Flash, are downloaded once;
they are
> just like loaded movies in that they are cached, but in RSL's case,
it's
> treated (for code purposes) as the same SWF. It should use the cached
SWF
> each time, same as loadMovie (unless you append a random date;
> SharedLibraries don't work like that; you use them, you don't load
them)
> 
> ----- Original Message -----
> From: "Scott Barnes" <[EMAIL PROTECTED]>
> To: <flexcoders@yahoogroups.com>
> Sent: Friday, April 01, 2005 12:26 AM
> Subject: [flexcoders] Creation/Destroy Queries...
> 
> So, got a few questions regarding how Flex does things. I've looked
> around and can't quite get a clear answer so if you MM Engineers feel
> like spending 2 mins here on this thread, i thankyou ;)
> 
> - Destroy/Create. In terms of doing this, in a cycle of approx 4000
> components that over say a period of 2 hours, i
> createChild/destroyChild will that do so in a memory effecient way
> (not bandwidth). In that does flash player/flex server keep asking for
> more memory every time i createChild? aswell as free that memory
> (eventually) when i destroy that child.
> 
> - createChild and creationPolicy. If I use createChild to instantiate
> a mxml component, and inside that component I have a creationPolicy
> attribute set, will the createChild take that on board - meaning if i
> have it set to queued or what not, will it "inherit" that setting?
> 
> - createChild and RSL. Same as above but if i createChild a declared
> RSL, is it possible that it will do so in the same way but without a
> download every time? (ie i take it createObject method attaches movie
> but double checking to make sure it doesn't ask for a new download
> each time).
> 
> - viewStacks and createChild. I typically want to create a viewStack
> at runtime / or embed and  if the viewstack container as
> creationPolicy set, when i use createChild (without specifiying one) i
> take it that setting carries forward.
> 
> - mx:Model/XML if i place that inside a MXML component, on compile
> time, does FLEX embed that said file inside the swf or does it request
> it be download once base assets have been initialized (I'm a bit
> sketchy on this part). I'm sure its a RTFM situation but I must be
> missing where that part is stated heh :)
> 
> Just thought I would confirm / ask some theories going around inside
> the ol noggin in regards the whole creation of objects as if these
> come up as i expect they will, it will be a nice step forward for my
> framework.
> 
> I basically plan to create/destroy whole screens (not all at once but
> partially on/off) situation as a user migrates through our entire FLEX
> intranet and because its going to look and smell like a thick-ware
> application, a user may end up keeping a browser window open for hours
> often even a week solid - now if they flip in and out of screens daily
> i'm concerned that memory may be deciding factor.
> 
> Of course its my job to follow best practices (minimize tag nestings,
> make sure i dereference vars for GC to mark as not needed and what
> not) - but I am also relying on the inner-framework to do this aswell
> and need to be aware of anything thats not sooner rather then later.
> 
> thanks for your help ;)
> 
> --
> Regards,
> Scott Barnes
> http://www.mossyblog.com <http://www.mossyblog.com> 
> http://www.flexcoder.com <http://www.flexcoder.com>  (Coming Soon)
> 
> Yahoo! Groups Links
> 
> Yahoo! Groups Links
> 
> Yahoo! Groups Links
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 


-- 
Regards,
Scott Barnes
http://www.mossyblog.com <http://www.mossyblog.com> 
http://www.flexcoder.com <http://www.flexcoder.com>  (Coming Soon)


  _____  

Yahoo! Groups Links


*       To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<http://groups.yahoo.com/group/flexcoders/> 
  

*       To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> 
  

*       Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/flexcoders/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply via email to