XOM performance compared

NAVIGATION

CATEGORIES

Java

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Java

XOM performance compared
8 answers - 512 bytes -
hello,
are there any performance comparisons between lets say XM and
dom4j/JDM etc?
I try to persuade some colleges at work to use XM instead of dom4j
(which has bitten some projects with some nasty details mostly issues
about whitespace handling) but they question the performance of XM.
Googling did not bring any real help, so I'd think I'll ask here
thanks a lot
christof
XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org
No.1 | | 185 bytes | |
csad7 (AT) t-online (DOT) de wrote:
hello,
are there any performance comparisons between lets say XM and
dom4j/JDM etc?
Nothing I'm aware of off the top of my head.
No.2 | | 885 bytes | |
Would be interesting. I'm not aware of such a thorough study. Having
said that, I'd be somewhat surprised if they were more efficient. It
probably also depends on the main usage pattern.

Wolfgang.

Jul 22, 2005, at 2:04 AM, csad7 (AT) t-online (DOT) de wrote:

hello,
are there any performance comparisons between lets say XM and
dom4j/JDM etc?

I try to persuade some colleges at work to use XM instead of dom4j
(which has bitten some projects with some nasty details mostly issues
about whitespace handling) but they question the performance of XM.

Googling did not bring any real help, so I'd think I'll ask here

thanks a lot
christof

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org
No.3 | | 1617 bytes | |
I did a simple benchmark test to compare XM and JDM performance. I
don't know if this makes sense, but, the test compared the contents of
the new Node to all the other Nodes in the Document. The Node was then
added to the Document in an order based on the contents of the Node.
XM and JDM performed very similarly.

Jason Mazzotta

Jul 22, 2005, at 6:51 PM, Wolfgang Hoschek wrote:

Would be interesting. I'm not aware of such a thorough study. Having
said that, I'd be somewhat surprised if they were more efficient. It
probably also depends on the main usage pattern.

Wolfgang.

Jul 22, 2005, at 2:04 AM, csad7 (AT) t-online (DOT) de wrote:
>
>hello,
>are there any performance comparisons between lets say XM and
>dom4j/JDM etc?
>>
>I try to persuade some colleges at work to use XM instead of dom4j
>(which has bitten some projects with some nasty details mostly issues
>about whitespace handling) but they question the performance of XM.
>>
>Googling did not bring any real help, so I'd think I'll ask here
>>
>thanks a lot
>christof
>
>XM-interest mailing list
>XM-interest (AT) lists (DOT) ibiblio.org
>
>>
>

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org
No.4 | | 1918 bytes | |
I did this test for Documents of various initial sizes, up to 500 nodes.

Jason Mazzotta

Jul 22, 2005, at 7:07 PM, jason mazzotta wrote:

I did a simple benchmark test to compare XM and JDM performance. I
don't know if this makes sense, but, the test compared the contents of
the new Node to all the other Nodes in the Document. The Node was then
added to the Document in an order based on the contents of the Node.
XM and JDM performed very similarly.

Jason Mazzotta

Jul 22, 2005, at 6:51 PM, Wolfgang Hoschek wrote:
>
>Would be interesting. I'm not aware of such a thorough study. Having
>said that, I'd be somewhat surprised if they were more efficient. It
>probably also depends on the main usage pattern.
>>
>Wolfgang.
>>
>Jul 22, 2005, at 2:04 AM, csad7 (AT) t-online (DOT) de wrote:
>>
hello,
are there any performance comparisons between lets say XM and
dom4j/JDM etc?

I try to persuade some colleges at work to use XM instead of dom4j
(which has bitten some projects with some nasty details mostly issues
about whitespace handling) but they question the performance of XM.

Googling did not bring any real help, so I'd think I'll ask here

thanks a lot
christof

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

>>
>
>XM-interest mailing list
>XM-interest (AT) lists (DOT) ibiblio.org
>
>>
>

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org
No.5 | | 702 bytes | |
jason mazzotta wrote:
I did a simple benchmark test to compare XM and JDM performance. I
don't know if this makes sense, but, the test compared the contents of
the new Node to all the other Nodes in the Document. The Node was then
added to the Document in an order based on the contents of the Node.
XM and JDM performed very similarly.

In practice this sort of task is almost inconsequential performance
wise. Most applications spend the vast majority of their time on either
input or output (i.e. parsing, tree building, and serialization) or
both. The speed of in-memory operations is normally so much faster it's
hard to even measure. I doubt it matters.
No.6 | | 1961 bytes | |
My co-worker did a very small test saying XM 1.0 did take about 10%
more time to load/build/etc the document he tested it with. course
this is not a real performance test but thats what he went with.
I too doubt dom4j will be much faster but they are accustomed to it and
there should be not disadvantages by changing (advantages I see in XMs
focus on correctnes. Simplicity for me is a big advantage too but I
myself did not use dom4j before).

But I was wondering if XM 1.1 will be a lot faster in some areas after
the discussions about performance optimizations on this list. Being only
a moderate I was not following everything in detail but had the
impression 1.1 should be much more optimized, is that true? When is 1.1
expected as a final version?

thanks
Christof

Wolfgang Hoschek wrote:
Would be interesting. I'm not aware of such a thorough study. Having
said that, I'd be somewhat surprised if they were more efficient. It
probably also depends on the main usage pattern.

Wolfgang.

Jul 22, 2005, at 2:04 AM, csad7 (AT) t-online (DOT) de wrote:

>hello,
>are there any performance comparisons between lets say XM and
>dom4j/JDM etc?
>>
>I try to persuade some colleges at work to use XM instead of dom4j
>(which has bitten some projects with some nasty details mostly issues
>about whitespace handling) but they question the performance of XM.
>>
>Googling did not bring any real help, so I'd think I'll ask here
>>
>thanks a lot
>christof
>
>XM-interest mailing list
>XM-interest (AT) lists (DOT) ibiblio.org
>
>>

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org
No.7 | | 1342 bytes | |
Christof wrote:
My co-worker did a very small test saying XM 1.0 did take about 10%
more time to load/build/etc the document he tested it with. course
this is not a real performance test but thats what he went with.
I too doubt dom4j will be much faster but they are accustomed to it and
there should be not disadvantages by changing (advantages I see in XMs
focus on correctnes. Simplicity for me is a big advantage too but I
myself did not use dom4j before).

That wouldn't surprise me. XM does quite a bit more work when building
than most parsers do.

But I was wondering if XM 1.1 will be a lot faster in some areas after
the discussions about performance optimizations on this list. Being only
a moderate I was not following everything in detail but had the
impression 1.1 should be much more optimized, is that true? When is 1.1
expected as a final version?

I think it will be quite a bit faster, maybe as much as a factor of two
on average so if it was only 10% slower before, it should really smoke
the competition now. :-) API and feature-wise 1.1 is essentially
complete. I'm just tweaking the performance as time permits. My plan is
to release 1.1 shortly after xml:id goes to final rec, since that's the
only unfinished standard 1.1 depends on.
No.8 | | 2435 bytes | |
Wrt. parsing, I just ran the ParseLoop.java performance measurement
program included in dom4j-1.6.1 on my usual testbed (includes
xerces-2.7.0). , dom4j/SAX/xerces seems to be roughly 1.5
times slower than xom-CVS on parsing/SAX/xerces, and dom4j/XPP pull
parser is 5 times slower than dom4j/SAX/xerces.

As always, this is just a small little data point, and it may or may
not apply to any given app use case, so please don't conclude too
much from that, and please don't start flame wars.

Wolfgang.

Jul 23, 2005, at 3:37 AM, Christof wrote:

My co-worker did a very small test saying XM 1.0 did take about
10% more time to load/build/etc the document he tested it with.
course this is not a real performance test but thats what he went
with.
I too doubt dom4j will be much faster but they are accustomed to it
and there should be not disadvantages by changing (advantages I see
in XMs focus on correctnes. Simplicity for me is a big advantage
too but I myself did not use dom4j before).

But I was wondering if XM 1.1 will be a lot faster in some areas
after the discussions about performance optimizations on this list.
Being only a moderate I was not following everything in detail but
had the impression 1.1 should be much more optimized, is that true?
When is 1.1 expected as a final version?

thanks
Christof
--
Wolfgang Hoschek wrote:
>
>Would be interesting. I'm not aware of such a thorough study.
>Having said that, I'd be somewhat surprised if they were more
>efficient. It probably also depends on the main usage pattern.
>Wolfgang.
>Jul 22, 2005, at 2:04 AM, csad7 (AT) t-online (DOT) de wrote:
>>
hello,
are there any performance comparisons between lets say XM and
dom4j/JDM etc?

I try to persuade some colleges at work to use XM instead of dom4j
(which has bitten some projects with some nasty details mostly
issues
about whitespace handling) but they question the performance of XM.

Googling did not bring any real help, so I'd think I'll ask here

thanks a lot
christof

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

XM-interest mailing list
XM-interest (AT) lists (DOT) ibiblio.org

Re: XOM performance compared

EMSDN.COM

It's a question for 'XOM performance compared' under 'Java'

Java

XOM performance compared