Setting Image to null is not good enough. Call load(null) on the Image before removing it from the display list and releasing references to it.
GC() is not deterministic. The only ways to test are to use the profiler, or run the app over thousands of actions and see if you eventually reach a stable number. System.totalMemory does not measure memory used by the browser and OS to actually render things and the "shrinks memory when minimized" problem has been seen before and is under investigation by the player team. Also, the debugger/profiler player can leak memory that isn't always shown in the profiler but may show up in System.totalMemory. But, System.totalMemory is the high-water mark. It is rare for pages to be released because of the way the player allocates memory, so it is always best not to create stuff that you don't need. Also, make sure you're on the latest player 9. The final test is to run your app over thousands of iterations on a release player with a release SWF and see if it eventually reaches a stable browser process memory number. Using debug SWFs or debugger player in such a test will skew results. From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of andrii_olefirenko Sent: Wednesday, October 29, 2008 8:01 AM To: [email protected] Subject: [flexcoders] Re: Memory issues ... garbage collection only running in IE (not FF or Safari) i still think that you could re-use window instances. After all, how many windows a regular human being is capable to deal with at one time - 7, 12,25? You just create a pool of instances and there will be *zero* startup time for the window and *zero* memory increase. Otherwise, you would need to create unlimited number of instances. When I was a little boy and programmed in Borland Delphi, I came up with the same idea for my applications - and i think this approach is still valid for Flex stuff :) Flex components by design are not light. for example, they could be references in static variables (i guess), which could prevent some objects from garbage collecting. There are "item renderers", they are designed to be numerous, but even they, they are cached by components like datagrid, list, etc. --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "e_baggg" <[EMAIL PROTECTED]> wrote: > > My original mxml was a bad example I guess. In my application, which > is a Flex app that has its own windowing (exactly like Windows)...when > I add and create Windows and close them, the browser CPU memory always > increments (except for IE when I minimize the browswer window and > memory is restored). When using System.totalMemory, I see some memory > gets cleaned up but not all of it and if I open and close the same > window multiple times, it is inconsistent to how much memory is given > back to the Player, but either way it continually increments. I use > weakReferences everywhere and call removeAllChildren() on the toplevel > containers and set the viewComponent to null when removing the > Mediator from the Facade (PureMvc). But yeah, when using Profiler, > which forces a gc(), all memory is correctly restored back the player. > Just not in runtime. The hunt continues... > > --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, > "andrii_olefirenko" <andriyo@> > wrote: > > > > i've tried your example and didn't notice any memory leakage. > > anyway, why do you need to create components and remove them, and > > create again the same components? It looks like you made up an > > artificial problem for yourself :) > > > > > > --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, > > "e_baggg" <e_baggg@> wrote: > > > > > > So I have an app in production which after 10 minutes of usage > began > > > to perform EXTREMELY slow, and users had to restart the app. (Flex > 3) > > > Windows and Mac...all browsers. I did some Profiling and did not > get > > > far. Whenever I take a Memory Snapshot, gc() is forced and all my > > > objects are correctly removed from memory. So why are they not > gc()'d > > > in normal runtime?? I know gc() only runs when new memory is > requested > > > and nothing is being drawn/rendered. Both seem to be OK on my > side. > > > > > > I have read extensively all the blogs and Adobe docs regarding > this > > > issue, including the event listener for ENTER_FRAME which calls > > > System.gc() twice. (http://www.craftymind.com/2008/04/09/kick- > > > starting-the-garbage-collector-in-actionscript-3-with-air/). This > > > unfortunately did not work for me. > > > > > > To simplify, I created a simple app that adds and removes RichText > > > fields. if I create 50 of them, then remove them all, then Add one > > > back, that *should* force a gc() but it does not. The FF memory > always > > > stays high. I noticed in IE, minimizing the browser window causes > a > > > gc() and my memory drops to a much lower #. > > > > > > > > > Has anyone seen or come across this? B/c of this issue, we're > pretty > > > much going to lose our customers and try to wing a html/ajax app > > > ASAP..so I'm scrambling to resolve this. > > > > > > Thanks in advance for any help. > > > > > > <?xml version="1.0" encoding="utf-8"?> > > > <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"; > > > creationComplete="init()" layout="vertical" > > > > <mx:Script> > > > <![CDATA[ > > > import mx.controls.RichTextEditor; > > > > > > private function removeit():void > > > { > > > this.removeChildAt(2); > > > } > > > > > > private function doit():void > > > { > > > var rte : RichTextEditor = new > > > RichTextEditor(); > > > rte.width=300; > > > rte.height=150; > > > this.addChild(rte); > > > } > > > ]]> > > > </mx:Script> > > > <mx:Button click="doit()" label="Add"/> > > > <mx:Button click="removeit()" label="Remove"/> > > > </mx:Application> > > > > > >
