XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Nov 23, 2004, at 4:47 AM, Elliotte Harold wrote:

> I wrote a benchmark of my own that just copies an existing document 
> manually (i.e. without using the various copy methods) so that it hits 
> everything in the Verifier. Profiling revealed a few hotspots, 
> particularly places where I should have been caching the length of a 
> string and using a toCharArray instead of charAt.
> However some of the optimizations you suggested seemed to have 
> negative effects on my VM. In particular, pulling the try-catch blocks 
> out of for loops appeared to slightly increase the time spent in those 
> methods. We may be at the point where optimizations are getting too 
> tightly tied to the idiosyncrasies of one VM or the other. :-(

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.

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.

As I mentioned in a previous mail, microbenchmarks such as your may 
give unrealistic results. Care to repeat tests with the BinaryXMLTest?