Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Attributes performance patch

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 <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Attributes performance patch
  • Date: Tue, 23 Nov 2004 14:42:41 -0800

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.





Archive powered by MHonArc 2.6.24.

Top of Page