Oh. It's to bad !!! Does anybody know to solve this problem ??
--- In flexcoders@yahoogroups.com, "André Rodrigues Pena" <[EMAIL PROTECTED]> wrote: > > <?xml version="1.0" encoding="utf-8"?> > <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"; layout="vertical"> > > <mx:VBox id="vBoxLeak" width="200" height="200" > backgroundColor="#eeeeee"/> > > <mx:HBox> > <mx:Button id="btnAddChilds" label="Add Childs" > click="onAddChilds_Click(event)"/> > <mx:Button id="btnRemChilds" label="Rem Childs" > click="onRemChilds_Click(event)"/> > </mx:HBox> > > <mx:HBox> > <mx:Button id="forceGC" label="Force GC" > click="onForceGB_Click(event)"/> > </mx:HBox> > > <mx:HBox> > <mx:Button id="btnCaptureMemory" label="Capture Memory" > click="onCaptureMemory_Click(event)"/> > </mx:HBox> > > <mx:TextArea id="txtArea" width="200" height="200" textAlign="right"/> > > <mx:Script> > <![CDATA[ > import mx.controls.Button; > > private function onAddChilds_Click (event:MouseEvent):void > { > for (var i:int=0;i<1000;i++) > { > vBoxLeak.addChild(new Button); > } > } > > private function onRemChilds_Click (event:MouseEvent):void > { > vBoxLeak.removeAllChildren(); > } > > private function onCaptureMemory_Click (event:MouseEvent):void > { > txtArea.text += System.totalMemory + "\n"; > } > > private function onForceGB_Click(event:MouseEvent):void > { > // unsupported hack that seems to force a full GC > try > { > var lc1:LocalConnection = new LocalConnection(); > var lc2:LocalConnection = new LocalConnection(); > > lc1.connect('name'); > lc2.connect('name'); > } > catch (e:Error) > { > > } > } > > ]]> > </mx:Script> > > </mx:Application> > > On 8/27/07, André Rodrigues Pena <[EMAIL PROTECTED]> wrote: > > > > Alex, I appreciate your reply but I still think there's something wrong > > regarding memory. I'm sending you an application that reproduces the > > situation I started my earlier post with. Flex does not releases all the > > memory it takes, even inducing garbage collection as I show in the demo > > application. If you repeat the experience over and over you will see that > > the memory lost is not likely to get back. > > > > So what is this? What can I do about it? > > > > On 8/25/07, Alex Harui <[EMAIL PROTECTED]> wrote: > > > > > > There are two major memory usage scenarios in Flex. One involves > > > creating a new instance of a component, displaying, and later destroying > > > it. The other involves bringing in one or more classes of components in a > > > module and trying to get rid of that module later when its classes are no > > > longer needed. > > > > > > Honestly, I don't know of any issues of the first kind at this point. A > > > major problem with ViewStack related components was addressed in Hotfix2, > > > and a DateField issue was either addressed in the same hotfix, or a > > > workaround was provided and the issue fixed for Moxie. A recent issue with > > > Menus was fixed for Moxie and a workaround was provided. I'm sure there are > > > still issues out there, and they should be filed as bugs so we can > > > investigate and fix them. I also encourage you to try to isolate problems > > > of this nature and post examples on this forum as often there can be a > > > misunderstanding of how memory management works in Flash/Flex. > > > > > > The second kind of issues is sort of a fact-of-life for Flex. The first > > > module to introduce shared code via Styles or Managers must remain in memory > > > to serve all other code. This has been explained on my blog.http://blogs.adobe.com/aharui/2007/03/modules.html. > > > The blog article includes an example of a way to deal with this situation, > > > although often the easiest way is just to include all managers in the main > > > app, and bring in styles via runtime CSS. > > > > > > As you'll see in the article, browser memory management has little to do > > > with it. It simply has to do with how GC works (described further elsewhere > > > on my blog) and how styles and singleton managers are shared. Any memory > > > changes when minimizing is probably due to IE releasing its own browser > > > resources, although the player may release some at that time as well. > > > > > > If you have further questions, this forum should be able to help you > > > out. In the future, please ask sooner before you spend time creating > > > eloborate infrastructures. > > > > > > -Alex > > > > > > ------------------------------ > > > *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On > > > Behalf Of *André Rodrigues Pena > > > *Sent:* Saturday, August 25, 2007 10:44 AM > > > *To:* flexcoders@yahoogroups.com > > > *Subject:* [flexcoders] Memory leaks > > > > > > Hi all, > > > > > > It might be a well-known that Flex has several memory issues. It doesn't > > > completely free the memory of the components you add runtime, when you > > > remove them from their containers, and when it comes to large- scale > > > applications, this is a huge concern. The way my co-workers found to pass by > > > it was to create a Javascript/Flex framework to allow Flex to load modules > > > in separate HTML frames and provide communication between them. So, when a > > > module gets out of scene, the browser frees the entire SWF. But this > > > approach limits the user interaction like drag-n-drop support between > > > modules. It's not natural. > > > > > > It seems that the browser may have a great part of the blame. They > > > realized, for instance, that Internet Explorer releases the memory when the > > > window is minimized and FireFox doesn't. > > > > > > I'm here to ask what else can be done regarding memory issues. And how > > > you professionals have dealt with it. > > > > > > Thanks > > > > > > -- > > > André Rodrigues Pena > > > > > > > > > > > > > > > > > -- > > André Rodrigues Pena > > > > > -- > André Rodrigues Pena >
