XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > Improves by some 12%. The benchmark was given in the mail: download 
> > the document contained in the zip file, and run deserialization with 
> > the nux BinaryXMLTest.
>
> I tried that, but NUX wouldn't compile against the main trunk of XOM 
> because of the various incompatible changes you've made. :-(

Sure, if you'd like to try this test, you need to copy over the other 
patches from the directory as well. They are all small, trivial and 
backwards compatible...

> But really I need something simpler that goes right to the heart of 
> the problem. Think of it as extreme benchmarking. We need unit 
> benchmarks that test one thing and one thing only. These benchmarks 
> might be informed by experience with actual applications, just as unit 
> tests would be informed by finding bugs in production code, but you 
> don't use the production code as the unit test for the bug. Instead 
> you write a much simpler case that exposes the bug. In this case a 
> much simpler case that exposed the slowness would be extremely 
> helpful.

This can be useful. The main problem is the eternal nature of 
microbenchmarks:
- How representative are they of real usage?
- How much are their results perturbed by unrealistic compiler 
optimizations? Methods can get inlined and branches can get optimized 
(or optimized away) in a way that would (almost) never happen in 
real-world apps. Memory cache locality is most of the time extremely 
good for microbenchmarks, but not at all for real big apps. Memory 
locality is an absolutely crucial issue in todays computer 
architectures (deep memory hierarchies with 1-2 orders of magnitude 
difference in latency between each of register <-> L1 cache <-> L2 
cache <-> main memory <-> disk <-> tape). BTW, locality is increasingly 
the main issue for garbage collection technology. To summarize, without 
care, microbenchmarks can be actively misleading. At least they can be 
difficult to interpret.

BinaryXMLTest is neither a real-world app nor a microbenchmark. It's 
somewhere in between, hence quite useful for specific benchmarks that 
are not too hard to reproduce. You can use it for binary serialization 
and deserialization, but it can be used for other purposes as well.

For example, for the question at hand, you give it one or more 
representative standard textual xml documents on the command line, it 
builds the XOM document via a normal Builder, then creates a binary 
representation of it, and then repeatedly reconstructs the XOM document 
from the binary. The overhead of the binary parsing has now become so 
low that it is not far from manually generating the XOM document in 
memory via new XYZ, appendXYZ, etc. It's almost like writing the manual 
tree construction code, except that it does not require writing that 
code. Simply tell the command line program the xml files you care 
about: no namespaces, tons of namespaces, small texts, large texts, 
many attributes, whatever...

Another way to use it is to benchmark nu.xom.Builder or 
nu.xom.Serializer with various configurations. In the former case, you 
can see that over subsequent xerces releases, hotspots are more and 
more shifting from xerces into XOM.

Wolfgang.