XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> I do suspect you're overestimating the prevalence of whitespace  
> only text nodes. Pretty printing is great for humans but in any  
> sort of XML situation where you care about performance, memory, or  
> size, one of the first things you do is throw away boundary white  
> space, ideally before the document is generated but if not when the  
> document is parsed. XOM makes it very easy to use a NodeFactory  
> that never builds these nodes in the first place.

Nice theory. But in practice, the performance impact of using a  
NodeFactory is so large that it is way faster to build the tree  
without a NodeFactory (that is, with NonVerifyingHandler) and then  
strip away thereafter, if so desired. I forgot the exact numbers, but  
they were not pretty.

As note in private some time ago, the current xom-1.1-CVS has a very  
different profile depending on whether a tree is build from 1) a non  
verifying Builder, or 2) a Builder with a custom NodeFactory, or 3)  
via the normal node constructors, or 4) the node copy constructors.  
The QName LRU patch would make XOM performance behaviour much more  
uniform. It would become faster for (2) and (3), have certainly  
negligible overhead for (1) and no overhead for (4).