XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > The additional memory (4 bytes) required per Node doesn't hurt much 
> > either, considering how much memory is consumed by all sorts of other 
> > info in node, element, text, etc. Perhaps Elliotte can profile memory 
> > by parsing documents with java -verbose:gc and look at the final max 
> > memory consumption.
>
> I find it very hard to stomach four extra bytes per node. In my 
> experience memory consumption is a huge problem for XML object models, 
> and prevents people from using XML far more often than speed does. 
> I've done extensive profiling on memory usage, and worked very hard to 
> reduce each class down to the bare minimum. I'm still not quite there. 
> They're a couple of indirections I can pull out, especially in 
> ParentNode and Element, but mostly XOM is pretty small.

Try parsing a couple of representative large documents with java 
verbose:gc. It will print the heap size on each gc cycle. See where the 
max heap stops when the program terminates. It's not particularly 
significant... See for yourself.

> To convince me to spend four more bytes per node, the speed increase 
> is going to have to be phenomenal, like a factor of ten on common 
> operations. I'm not going to be convinced by 30% on one method.

Nobody claimed 30%. A better way of thinking about it is not percent 
but order of magnitute: linear becomes constant.

> And even then, I might push this off into a separate Ant target.

That wouldd be absolutely fine with me :-)