XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Nov 23, 2004, at 9:13 AM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
>
>
> > It would help to know on which VM/OS you ran the tests. My experience  
> > is that client VMs can easily be a factory 5 slower for XOM apps. JDK  
> > 1.5 server VM is fastest, unsurprisingly. It is also significantly  
> > faster than 1.4.2 server VM. MacOSX does not have a server VM and is  
> > far from a throughput environment (even though a very nice  
> > development environment). I run benchmarks on Linux JDK 1.5 server  
> > VM, even though I develop mostly on MacOSX.
>
> I just ran them on Mac OS X 10.3 with Java 1.4. If we really are at a  
> point where swapping the VM and platform makes that big a difference,  
> then I'm not sure how much optimization I should do. It's way too easy  
> to tie things to closely to one architecture.

MacOSX usage explains your results. It's a client VM (-server has no  
effect) and Apple has a long history of "less than outstanding" Java  
support. It seems they never got around to do server VM porting due too  
limited resources, experience, or interest (pick your choice). They  
seem to be content with something that merely works correctly (and it  
is true that for development it works like a charm). I would not be  
surprised if Apple did not also port other Sun VM internals that are  
crucial for performance.

I've given up profiling on MacOSX/JDK 1.4 a long time ago. The profiler  
output is mostly meaningless, perhaps because Apple also did a lousy  
job at porting VM integrated profiler support. The only profiler that's  
trustworthy is the JDK 1.5 cpu=samples profiler.

On the question on which VMs to optimize for, I'd say pick the ones  
where throughput apps are typically deployed on: server VM. That leaves  
toCharArray as the wrong strategic direction.

> > Profiling tools other than '-server   
> > -agentlib:hprof=cpu=samples,depth=10' on JDK 1.5 tend to greatly  
> > perturb results, sometime to the point of making them meaningless.  
> > See  
> > http://java.sun.com/developer/technicalArticles/Programming/ 
> > HPROF.html
> > > toCharArray instead of charAt
> > is the wrong strategic direction based on my PCDATA tests. the better  
> > the compiler, the more charAt and its checks can be optimized away,  
> > and the more the toCharArray memory copy degrades performance (and  
> > memory locality). As I said my PCDATA tests were on JDK 1.5 server  
> > VM, Linux.
>
> toCharArray() does worry me a bit, and I've been careful to test it  
> before using it, but when I've profiled it on Mac OS X and Linux with  
> Java 1.4 it does make a difference.


> > As I mentioned in a previous mail, microbenchmarks such as your may  
> > give unrealistic results. Care to repeat tests with the  
> > BinaryXMLTest?
>
> It seems more fruitful to benchmark based on standard XOM rather than  
> the NUX fork. The test I devised is basically the same thing as your  
> test, except that I load up a real XML document first instead of a  
> BNUX document, but then I proceed to create a copy of that document by  
> calling constructors, appendChild, addAttribute, etc. so it's a pretty  
> good simulation of creating a whole document from scratch in memory  
> without any of the back doors the copy methods and the Builder use.  
> See
>
> https://xom.dev.java.net/source/browse/xom/src/nu/xom/benchmarks/ 
> Reproducer.java?rev=1.1&content-type=text/vnd.viewcvs-markup

Seems fine, yes.