Results 1 to 2 of 2

Thread: Which is faster? Parsing XML using the XML DOM or SAX or parsing a recordset

  1. #1
    PowerPoster
    Join Date
    Jun 01
    Location
    Trafalgar, IN
    Posts
    3,438

    Which is faster? Parsing XML using the XML DOM or SAX or parsing a recordset

    It looks like this could be placed in a number of different forums but since I'm working with XML I'll try here.

    Okay, I'm working with a legacy classic asp application that either displays data in graphs or tables. For the graphs we use a graphing component that likes XML and since we already have the XML, we use xslt to display the data in a table if that is the users preference. The graphs work well regardless of the amount of data returned in the XML. With the tables, we do some pagination so those load well also. The area we have a problem is if the user want to generate csv file from the XML data.

    In this case we are passing the xml to a DLL that parses the xml using the XML DOM and when done sends it to the browser. If there are a large number of records in the XML file the script times out before the processing completes.

    As stated above, we are using the XML DOM for processing right now. Would we realize any performance gains by switching to SAX or would gathering our data into a recordset and parsing the recordset be any quicker?

    I have never used SAX but from the quick research I have done, I'm not sure it is the way to go since I will be using every element in the xml when generating the csv files.

  2. #2
    PowerPoster techgnome's Avatar
    Join Date
    May 02
    Posts
    21,655

    Re: Which is faster? Parsing XML using the XML DOM or SAX or parsing a recordset

    SAX processing would be the fastest... but it comes at a cost... it's a bit more complicated to setup... the SAX parser works by raising events every time a node is encountered.... opening and closing. So in the open tag event, you would then need to check to see that node caused the event, keep track of where you are in the heirarchy, determine if you need to keep track of the data... then on the closing node event, again, check to see what node fired the event, gather everything you've saved up and store it (or display it, or what ever). You can also only go forward. that's because the SAX parser works like a stream... it's just data continuously coming in... And it's read only... so you can't find a node, and reset There are more than just the two events, there's actually quite a few events you can tinker with. SAX parser is great with high speed processing of large XML files... just as long as you don't have any expectation of writing data back into the XML stream.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.-I also subscribe to all threads I participate, so there's no need to pm when there's an update.*
    *Proof positive that searching the forums does work: View Thread *
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *
    * Use Offensive Programming, not Defensive Programming. * On Error Resume Next is error ignoring, not error handling(tm).
    "There is a major problem with your code, and VB wants to tell you what it is.. but you have decided to put your fingers in your ears and shout 'I'm not listening!'" - si_the_geek on using OERN

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •