Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Canonicalizer Performance

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Sean Truman" <struman AT nuparadigm.com>
  • To: "Elliotte Harold" <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Canonicalizer Performance
  • Date: Mon, 28 Aug 2006 10:30:19 -0500

This is being used in the real world by software developed by the
government, it is actually produced by AXIS.

Sean

-----Original Message-----
From: Elliotte Harold [mailto:elharo AT metalab.unc.edu]

Sean Truman wrote:
> I have a 3MB xml ( http://download.nuparadigm.com/xom-issue/test.xml )
> file
> that I am trying to canonicalize and it is taking close to 14 Minutes
> for
> xom on a P4 3.2 with 1GB ram to canonicalize it. Any idea?
>

There's something very unusual about your test case document. It has
over 3000 different namespace prefixes, many of which seem to point to
the same three or so namespaces. That's the first thing I'd look at I'd

look since XOM has certainly not been extensively tested with documents
like that.

Is there a reason you're doing this? If real-world documents like this
exist, then this has some implications for other optimizations we've
considered as well.

I suspect what's happening is that this is machine generated XML.
Machine-generated data (not just XML data either) often tends to produce

extreme cases like this that violate people's natural assumptions about
maximum limits and expose bugs in code that assumed people would never
do things such as write variables with names longer than 256 characters.

Indeed people wouldn't, but programs do. Machine generated code has
broken a lot of compilers. Your code may be violating some implicit
assumptions in XOM.




Archive powered by MHonArc 2.6.24.

Top of Page