riawolf

I too have the same problem, and i tested it with preload profiler and with flashdevelop profiler. With flash develop profiler i can even look inside the PropTween Objects. While it is not a memory leak, but something funky is going on in there. When i leave the player alone for 5 min, the values are there and im tracing trace("current memory:", System.totalMemory); i get current memory: 16412672, all tweens are done, 5 min idle etc. However after forcing GC trace result immediately drops to current memory: 15040512. And PropTween count and memory values drop to 0. Why is it that flash player waits until forced to GC, 5min+ doing nothing? Id does clear other objects but not PropTween

Try profiling this code, i know its a very specific set of conditions, yet it illustrates the problem package { import flash.display.Sprite; import flash.events.Event; import flash.utils.setTimeout; public class Main extends Sprite { private var _array:Array; private var _xml:XML; public function Main():void { if (stage) init(); else addEventListener(Event.ADDED_TO_STAGE, init); } private function init(e:Event = null):void { removeEventListener(Event.ADDED_TO_STAGE, init); setTimeout(test,5000); } public function test():void { var xmlString:String = ''; var nodeString:String = ''; for (var i:int = 0; i < 50; i++) { xmlString += nodeString; for (var j:int = 0; j < 50; j++) { xmlString += nodeString+''; } xmlString += ''; } xmlString += ''; _xml = new XML(xmlString); _array = []; for each(var node:XML in _xml..node) { //_array.push(node); // memory leak; Memory:180,691,640 during runtime _array.push(new XML(node.toXMLString())); // no memory leak; Memory:5,290,963 during runtime } } } } Edit: I used flashdevelop SWF Profiler, not the most reliable tool i must say, System.totalMemory and windows Task manager showed normal memory amounts for this example even though SWF Profiler went totally crazy on me. So i started to play around. After tweaking the iterators for a while, i started to notice that memory test results became weird, spikes of memory if the cycle is over ~5000 iterations in the for each segment of the code. Maybe if you try recursive processing like in XMLLoader you will be able to recreate more controlled results

in parseLoaders function there is a statement for each (node in xml.children()) { parseLoaders(node, queue, toLoad); } this causes the XML object to be fully cloned, as node.parent() has access to parent node in XML, therefore every node and every sub node has access to the full XML tree, however it is not the same object but rather clones of it. In my application, this caused to have 522 XML objects created during runtime and total memory amount used was 42MB the quick solution is to turn the node object into string and parse it again as XML, this reduced the memory amount drastically down to under 1MB for each (node in xml.children()) { parseLoaders(new XML(node.toXMLString()), queue, toLoad); }