XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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.