XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Wolfgang Hoschek wrote:


> In this context here, it's meaningful for benchmarking purposes.
> Let's not get into religion about binary xml. If use case's requirements 
> do not justify binary xml, don't use it, by all means.

That's not really my point. What I meant was that in the vast majority 
of use cases all the time gets eaten up in one of three places:

1. Parsing (including tree construction)
2. Serialization
3. Whatever algorithms are being applied to the data in the XML document.

There's nothing I can do about 3. 1 and 2 I can play with, but your 
tests aren't touching these because you're not actually parsing or 
serializing XML. Therefore your codec tests tend to identify as hot 
spots parts of the code that are simply not going to show up in almost 
every other program, because they'll be completely swamped by the cost 
of 1parsing and serialization.

I tried to test the getChildCount() by cloning an empty element 10,000 
times. That only took 3 milliseconds total, so I bumped it up to 100,000 
times and then it took 30 milliseconds. These are round numbers. It 
varied by 10-20% from run to run and the version that called 
getChildCount was not reliably faster than the one that didn't.

> Having the childCount() check in there clearly does not harm any 
> document flavour. If can only have positive effects.

It's an extra method call when copying an element that does have 
children (the more common case I think). Is the amount of time spent in 
that method call significant? Probably not, but as far as I can tell 
neither is the time saved by calling it for an empty element.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim