|
I don’t believe changing the
viewstack children to applications will solve your problem. What you can
do is tell the ViewStack to destroy the children that aren’t showing, but
there’s no guarantee that you’re going to give the memory back to
the system. This is one of the things we’re focusing on in the next
Player. You could also run the profiler and see if there are particularly
expensive methods being called more often than you think. Basically run
the profiler a few times, the first time just let the application start, that
will give you a baseline. The next time run through the app once, that
will show you everything executing at least once. And the last time run through
the code where you’re switching screens a lot in case you think there’s
a memory leak. See what methods are getting called a lot more that 3rd
time and maybe you’ll catch something. Matt From:
[email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Valy Sivec Hello, I've checked the archived email and saw
some people having the same questions in regards with the way garbage collector
works. Unfortunately, I wasn't able to find anything that would help. Is there
anyone out here that know how the GC works and what we need to know to avoid
memory leaking... For example I'm not sure that loading/unloading am mxml via
mx:Loader will ever free up the memory or will continue to add on top of the
used memory...... I have the same question for view
stacks...For a large app is it safe to group multiple screens under the same
view stack or using separates applications would be the way to go.... Thanks for your patience, Valy
On 5/10/05, Valy Sivec <[EMAIL PROTECTED]> wrote: Do you Yahoo!? Yahoo! Groups Links
|

