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" <[email protected]> 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 > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- Spencer Markowski The Able Few [EMAIL PROTECTED] 314.631.5576 _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
