Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Some minor issues

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Some minor issues
  • Date: Mon, 6 Dec 2004 08:23:34 -0800


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.





Archive powered by MHonArc 2.6.24.

Top of Page