XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > I've mentioned before the problems involved with generating and 
> > interpreting meaningful benchmarks, in particular microbenchmakrs. As 
> > always, my tests use the binary codec, which is a meaningful way to 
> > measure the extent of any real improvements in this area.
>
> I question how meaningful that particular case is. When you start with 
> something that's not XML, and then generate something that's not XML, 
> it doesn't really match a typical usage pattern.

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.

> There's also the concern that it's not just the application being 
> benchmarked. It's the documents. Optimizations for one style of 
> document may not apply or even have negative effects for others.

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

> For instance, so far I have not been able to reproduce your result 
> that short-circuiting nonrecursiveCopy (now copyChildren) was 
> noticeably faster than just letting it run out. In my tests it ranged 
> from a couple of percent faster to a couple of percent slower from 
> run-to-run.

No surprise. The new, substantially faster codec is in CVS only, and 
has not yet been released. What has been released so far does not use 
new Element(element) or copy(), among other things. I can send you the 
CVS version if you like.

Wolfgang.