I had a project recently where I was parsing huge XML datasets... To get the speed and memory efficiency I needed, I ended up avoiding the XML object altogether. I loaded the XML as a String instead (using LoadVars), and split it into page sized chunks that I could parse on-demand later. String-splitting by node name is tricky, but doable. It's not very scalable: if the format of the xml changes, I'll probably have to rewrite my parser. But it got around a nasty problem where the XML object wasn't being cleared from memory... as I recall, it was using over 40 MB of RAM for 1 MB of XML data!!
I'll be glad when I can release an AS3 version and take advantage of E4X. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL Sent: Saturday, January 07, 2006 9:52 AM To: Flashcoders mailing list Subject: Re: [Flashcoders] Massive XML files and Flash This has been discussed countless times, and everytime all reach the same conclusion; you cannot do anything when XML.parseXML is run. The function has been improved in 3 releases (5, 6, and 7), but it's still single-threaded, and does not scale to meet larger XML datasets. If during testing it doesn't work out, you'll have to throw smaller chunks of XML at it over time. The typical scenario is: - show loading bar "Parsing..." - 1 frame later, parse - 1 frame after parsed, hide loading bar For optimizing your traversel search the archives, this has been discussed 10 billion times. However, to repeat: - use attributes vs. nested nodes - make references to everything. Flash 7 is optimized for local registers (local variables inside of functions) - additionally, those references prevent re-parsing, such as childNodes: var nodes:Array = this.firstChild.childNodes; Then use nodes throughout the rest of your code vs. re-declaring childNodes - use backwards while loops while(i--) - where applicable use nextChild vs. childNodes ----- Original Message ----- From: "Spencer Markowski" <[EMAIL PROTECTED]> To: "Flashcoders mailing list" <flashcoders@chattyfig.figleaf.com> Sent: Saturday, January 07, 2006 9:42 AM Subject: Re: [Flashcoders] Massive XML files and Flash So then... does anyone know of any solutions to speed up the 'parsing' process? Is there a way to pause the parser, do something else, and then resume parsing? (It sure would be nice if we could do two things at once) Is anyone really having trouble with the XML Object's parser or is it developer defined traversal routine pulling from the DOM that is taking up time? I'm also working with massive amounts of XML data and cannot find a way to speed up my parsing routine. (For one set it takes 10+ seconds to release it's grip on the processor. Not allowing the user to do anything, of course) This will all move to a database in the near future, but the speed issue is not in Macromedia's XML object parsing the data, it's in my traversal of it. I've tried a few different techniques, yet, it's clearly not an issue of the XML objects onLoad parse. -sp On 1/7/06, Johannes Nel <[EMAIL PROTECTED]> wrote: > > XPath != *native* E4X > i realise this, correct xml parsing is still faster while xpath is a > comfort > library to use when speed is not essential. xfactorstudio is the best and > most complient xpath. have not used MM xpath since 7.0, but its api is > extremely limited the best sollution thus far without/minimil server side > code is xslt. e4x will mature with beta and release. currently (without > using much of it) i find it slow (since my only experience with it is > reading bout it and playing with it maybe) . the best sollution is to use > remoting and server code and if possible hire a contractor for 2 weeks to > backend > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- Spencer Markowski The Able Few [EMAIL PROTECTED] 314.631.5576 _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
