Thanks Rick for your comments. The test app I sent is only meant to see the issue, not as a real world use case application. I ran with the code you sent me and here are some details that might interest you:- * Your test file size is !1.8M, so it stabilize at ~700M RAM as you said. * 5M file size will go up to ~1.2G RAM (in 50 assignment), after that I crash slowly. * 10M file size will go up to ~1.2G RAM (in 20 assignment), after that I crash slowly. * 20M file size will go up to ~1.2G RAM (in 8 assignment), after that I crash slowly
So, maybe those operations will stabilize eventually, but at what memory levels, 4G RAM or 5G RAM, I don't really know. I reached this summary:- Don't do "var a:XML = XML(str);" if your "str" is more than 1Meg, Flash will be asking for memory that can be higher than 1.2G, even though you are reusing the variable or empyting it. Thanks all, I'lam --- In [email protected], "Rick Winscot" <[EMAIL PROTECTED]> wrote: > > I'lam - > > > > I ran your example out of the box on the 25k line xsl spec I mentioned > earlier and could see an erratic memory pattern. However, I agree with Alex. > I could see no appreciable leak. As a matter of fact, the pattern was > indicative of thrashing (over allocation). So - I looked at your code. and > could see that you are using an endless loop that re-loads data with a > completion event - which won't allow AVM2 to generate an optimized footprint > and precludes garbage collection. It's a poor design. > > > > To fix the problem, I added a timer that faithfully reloads the data at five > second intervals and voi-la! After 60 seconds the application stabilized > (I've attached a screen shot). I ran a few more tests but came to the > following conclusion: > > > > 1 . You are loading far too much data. chunk it or junk the approach. If > possible, load deltas only (since last refresh) and/or use data objects. If > you absolutely must load 20mb of data as you have designed it - you must > give the app time to process the data fully _and_ start recovering before > loading another babod (Big Ass Blob of Data). > > 2 . Slim the data down. Convert the data to a symbolic representation. (i.e. > instead of <number>255</number> use 0xFF). Is using XML a requirement? Have > you considered using AMF? > > 3 . Loading data in an endless loop will always perform poorly. Load what > you need - need what you load - load it only when you need it. If your > loading mechanisms aren't purposeful. expect to see strange results. > > > > Here are a few things to chew on. ActionScript is not a compiled language. > String operations have an immense cost. Performance is always a trade off - > you can't have your cake, eat it and rub it on your thighs too. If you want > to use Flex you have to play by the rules. If you understand the rules you > can learn to bend them a little (and when not to). Garbage gets collected on > Thursday around here. I don't know when on Thursday but by the time I come > home at night the man has done his job. Let me say it this way. I don't know > when AVM2 goes through a collection cycle. I really don't care. as long as > it gets done. Bad code performs badly. consistently. > > > > Rick Winscot > > > > > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Ilam Mougy > Sent: Monday, March 31, 2008 1:25 AM > To: [email protected] > Subject: [flexcoders] Re: memory leak in converting string to xml > > > > I did use URLLoader in my real stuff (to show progress bar loading), > still the same issue. > > After I did the test app, it is clear it is not a conversion or > download or whatever, it is a basic flaw in the GC and anyone will hit > it if they use memory transaction that is big enough (var a:String = > b; //will do it if b is big enough). My machine is 2G, so it will > freeze after 1.2G, others might freeze at the 500M levels. > > This is in the core of GC algorithm, and a fix could be as simple as > instead of kicking the GC after "n" allocation, should be done based > on some ratio the OS offers for free memory. The fact that no one > knows when the GC is kicked in, tells me that it is not well defined > feature, just thrown there in the player without stress testing. > > Thanks, > I'lam > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , > "Rick Winscot" <rick.winscot@> > wrote: > > > > In my tests I used the URLLoader. and didn't see this 'leak' at all. > Have > > you tried any alternate paths to load the data? > > > > > > > > Rick Winscot > > > > > > > > > > > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] > On > > Behalf Of Ilam Mougy > > Sent: Saturday, March 29, 2008 9:26 PM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Re: memory leak in converting string to xml > > > > > > > > Well, it looks like this is a known "deferred" issue. > > Looks like the player (not the Flex sdk) is the one that leaks when > > you convert string to xml > > (https://bugs.adobe.com/jira/browse/SDK-11982), but this means, if you > > have a RIA that asks for repeated xml files, it will be crash! > > > > I wish I know any way to convert to xml and avoiding the string route. > > Anyone? > > > > Thanks, > > > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> , > > "Ilam Mougy" <imougy@> wrote: > > > > > > I am almost giving up on this issue, I don't know any work around. > > > Here is example, in AS:- > > > > > > var strToBeXML:String = '<root>...</root>';// this is huge string, > > > 20Meg xml for example. > > > myTrace('***** memory before xml conversion (A): ' + > > System.totalMemory); > > > var xmlObj:XML = new XML(strToBeXML); > > > myTrace('***** memory after xml conversion (B): ' + > System.totalMemory); > > > // now, there is no way to get rid of this increase in memory! > > > xmlObj = null; > > > myTrace('***** memory after xml deletion (C): ' + System.totalMemory); > > > > > > protected function myTrace(str:String):void{ > > > forceGC(); > > > trace(str); > > > } > > > public function forceGC():void{ > > > try { > > > new LocalConnection().connect('foo'); > > > new LocalConnection().connect('foo'); > > > } catch (e:*) {} > > > } > > > > > > (C) is always similar to (B). > > > Any hits? I need to get rid of this xml object memory allocation and > > > I can't. I think I read all the articles about memory leaks. I > > > haven't used Flex 3 yet, but I am sure if I try and it says there is a > > > leak, so what, what should I do? > > > > > > Thanks for your help. > > > > > >
