Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] [ANN] nux-1.0beta2 release

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] [ANN] nux-1.0beta2 release
  • Date: Sun, 14 Nov 2004 00:51:09 -0800

On Nov 13, 2004, at 7:34 PM, Elliotte Harold wrote:

You mentioned a couple of hot spots:

1) allow to selectively disable the Verifiersanity checks for URIs and PCDATA via System properties, and 2) maintain an internal String instead of an UTF-8 encoded byte array in Text, which eliminates the expensive character conversions implied for each access to a Text object. This increases performance at the expense of memory footprint.

I can certainly believe #2. #1 surprises me. Did you find this while serializing and deserializing or doing something else? Generally XOM should not be verifying PCDATA when serializing or parsing, only when creating new nodes from a non-parser source.

#1 and #2 are hotspots when using the BinaryXMLCodec. #2 for serialization, #1 and #2 for deserialization. The Codec does not use a Builder, it converts *directly* between a xom tree and the binary format (more efficient). Since only nu.xom.* classes can use the package protected non-checking build methods, the codec can't use those, and hence the sanity checks show up as hotspots. [Another first-class citizen case]


XOM does check namespace URIs (on parsing only) because parsers don't do a full job of that. Hmm, looking at the code now I do see a way I could cut a chunk of that out though. I'm not sure how big the effect would be, but it might save some time. There are also a few places in the URI verification code I could replace String concatenation with StringBuffers, though again I'm not sure how big the effect would be.

#1 Right, the Verifier URI sanity checks are quite involved, unfortunately. The JDOM checks are less involved (but also less strict). If you look at how java.net.URI is implemented (someone seems to have worked real hard on that code) you might, with luck, find some tricks that can help.

#2 UTF conversion of large strings is fast, but for small strings (the common case) it is the opposite (setup costs), and hence Text is a hotspot as well.

Those things show up because the rest of the codec is dammned fast. You might not see them as hotspots otherwise.
Try running nux.xom.tests.BinaryXMLTest with a profiler to see for yourself.

Cheers,
Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page