Such is the nature of player memory management. It doesn't free up pages as aggressively as you might want it to, nor does it compact memory, so the first allocation grabbed a bunch of pages that aren't fully cleaned, but reused after that.
________________________________ From: Gordon Smith Sent: Wednesday, August 29, 2007 12:37 PM To: [email protected] Cc: Alex Harui Subject: RE: [flexcoders] Re: Memory leaks Here are the results I get when I start by doing Force GC and Capture Memory and then repeatedly do Add Childs, Rem Childs, Force GC, Capture Memory: 4943872 6393856 6664192 6627328 6770688 6803456 6815744 6815744 6815744 6823936 6815744 There is no memory leak because continuing to add and remove children does not continue to use more memory. However, I'm not sure what explains the initial increase from 4.9MB to 6.8MB, and why it takes more than one cycle to get to more-or-less steady-state. Any ideas, Alex? - Gordon ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of filipemlopes Sent: Tuesday, August 28, 2007 6:52 PM To: [email protected] Subject: [flexcoders] Re: Memory leaks Oh. It's to bad !!! Does anybody know to solve this problem ?? --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "André Rodrigues Pena" <[EMAIL PROTECTED]> wrote: > > <?xml version="1.0" encoding="utf-8"?> > <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml > <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. <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:* [email protected] <mailto:flexcoders%40yahoogroups.com> [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] *On > > > Behalf Of *André Rodrigues Pena > > > *Sent:* Saturday, August 25, 2007 10:44 AM > > > *To:* [email protected] <mailto:flexcoders%40yahoogroups.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 >
