Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Attributes performance patch

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 AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Attributes performance patch
  • Date: Mon, 22 Nov 2004 17:52:52 -0800


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.





Archive powered by MHonArc 2.6.24.

Top of Page