Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] More parsing performance patches

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] More parsing performance patches
  • Date: Fri, 22 Jul 2005 12:06:42 -0700


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).





Archive powered by MHonArc 2.6.24.

Top of Page