IBM xml4j parser vs. Datachannel

[Erik James Freed]

We are in kind of interesting position to comment on what you are doing
because we just ported our code from Datachannel to IBM. While we did no
rigorous objective testing, it is is pretty easy to tell differences in
performance because of obvious user interactivity changes.

We noticed no dramatic change one way or the other. However our code does a
'visit all' pattern and when we turn on the 'deferred' DOM processing, it
slows way way down (guessing factor of 4-5). Works fine in the non-deferred
(full) mode. The default is I believe the deferred mode, so I would try
turning this off. (if you are using the DOM parser)

One thing I have noticed is that the datachannel parser running on the MS
JVM had no memory leaks, the IBM seems to have memory leaks. (NOTE: this
remains unsolved and perhaps is my problem, though I am beginning to doubt
it) IBM said that running under JProbe they had no leaks, but were aware of
possible problems in certain JVMs (MS?) for complex graph structures (DOM).
I am just now running tests to localize the problem, but I am a bit
concerned. I would be interested if you (or anyone out there) experiences
leaks...

Clearly we need performance tests to go along with Dave Brownell's fine
conformance tests!

good luck!

erik

> -----Original Message-----
> From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
> Mike Lepley
> Sent: Tuesday, October 12, 1999 3:39 PM
> To: xml-dev at ic.ac.uk
> Subject: IBM xml4j parser vs. Datachannel
>
>
> At our firm we are considering using the XML4j parser.
> The XML4j parser has gotten some excellent reviews.
> That is why I cannot understand the test results that I've done myself.
>
> For example:
>
> IBM XML4j
> ---------
>                            Time to
> File size  |  Tags  | visit all
> --------------------------------
> 3kb           100        .55s
> 2,229kb       7000       8.51s
> 6,368         20000      115.29s
>
> and the Datachannel
>
> Datachannel
> -----------
>                            Time to
> File size  |  Tags  | visit all
> -------------------------------
> 3kb           100       .13
> 2,229kb       7000      2.99s
> 6,368kb       20000     9.76s
>
> And I have many more data points all the way to a 10MB file.
>
> Has anyone else experienced such poor results with the IBM parser?
> Why is there such a difference?  I've included my sample code for
> the XML4j
> parser.
>
> Thanks in advance!
> Mike
>
> ---------------------------------
>
> import java.io.*;
> import java.net.*;
>
> import com.ibm.xml.parsers.*;   // For the IBM Parser stuff
>
> import org.w3c.dom.Attr;
> import org.w3c.dom.Document;
> import org.w3c.dom.NamedNodeMap;
> import org.w3c.dom.Node;    // The W3C definition of a node
> import org.w3c.dom.NodeList;
>
> public class DOMibm4j
> {
>    int ELEMENT_NODE = 1;
>    public static String szText = "";
>
>    Document doc;
>
>    public DOMibm4j (String file, String sch /**, RichEdit re */)
>    {
>    try
>
>
>    com.ibm.xml.parsers.DOMParser parser =
>    new com.ibm.xml.parsers.DOMParser ();
>
>    parser.setValidating (false);
>          parser.parse (file + ".x");
>
>    doc = parser.getDocument ();
>       }
>       catch (Exception e)
>       {
>          e.printStackTrace();
>          return;
>    }
>
>       // Let's loop through all the nodes and look at them...
>
>       for (int i=0; i < doc.getChildNodes().getLength (); i++)
>       {
>          Visit (doc.getChildNodes ().item(i), 0);
>       }
>    }
>
>    public void Visit (Node node, int spaces)
>    {
>       // Recursively visits every node under this top node
>
>       // Make sure that it's not an attribute or CDATA or processing
> instruction, etc.
>
>       if (node.getNodeType () == ELEMENT_NODE)
>       {
>          int length = node.getChildNodes().getLength ();
>          for (int i=0; i < length; i++) { Visit
> (node.getChildNodes().item(i), spaces+5); }
>       }
>    }
> }
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the
> following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)