Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Some minor issues

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] Some minor issues
  • Date: Mon, 6 Dec 2004 13:26:16 -0800


I tried to test the getChildCount() by cloning an empty element 10,000 times. That only took 3 milliseconds total, so I bumped it up to 100,000 times and then it took 30 milliseconds. These are round numbers. It varied by 10-20% from run to run and the version that called getChildCount was not reliably faster than the one that didn't.

Yet another fatally flawed benchmark. Any benchmark that runs < 30 secs (or so) tests VM init, class loading, etc, but unfortunately not the piece of code we're trying to improve here. 30 millis is a smallish fraction of what it takes a VM to simply start up, so the VM never sees the test as a hotspot, what we're trying to benchmark is probably not even compiled but simply interpreted. There are lots of other gotchas when benchmarking with hotspot engines. To get some background, try to attend a talk from hotspot engineers when you get a chance. Here one such talk "how not to write a microbenchmark" http://servlet.java.sun.com/javaone/sf2002/conf/sessions/display -1816.en.jsp

Here is another microbench, still very flawed, but not fatally.

public static void main(String[] args) throws Exception {
int runs = Integer.parseInt(args[0]);
Element elem = new Element("item");
int checksum = 0;
for (int i=0; i < runs; i++) {
Element copy = new Element(elem);
checksum += copy.getChildCount();
}
System.out.println(checksum);
}

It's still completely unrepresentative but it highlights that there clearly is a significant difference here (speedup > 2). The first run uses no getChildCount() > 0 check, the second run does (all JDK 1.5 server VM):

[grolsch /home/portnoy/u5/hoschek/tmp/tmp/firefish] time bin/fire-java gov.lbl.dsd.firefish.trash.XomCopyElem 500000000

0

real 0m50.453s
user 0m49.410s
sys 0m0.390s
[grolsch /home/portnoy/u5/hoschek/tmp/tmp/firefish] time bin/fire-java gov.lbl.dsd.firefish.trash.XomCopyElem 500000000

0

real 0m21.502s
user 0m21.080s
sys 0m0.220s

In any case, the difference is also very significant with the binary codec, which is not a microbench, but more a macrobench. It equally applies to anyone building XOM trees in memory using similar "copy tricks".


Having the childCount() check in there clearly does not harm any document flavour. If can only have positive effects.

It's an extra method call when copying an element that does have children (the more common case I think). Is the amount of time spent in that method call significant? Probably not, but as far as I can tell neither is the time saved by calling it for an empty element.

The amount of work that needs to be done when there's > 0 elements completely fades in comparison to the cost of a getChildCount() > 0 check. Look at your code and see what it has to go through even for a single child element...

It seems to me we are both wasting more time than necessary with such mails flying back and forth. After all there's plenty of other things to do. If you don't believe it, simply don't apply the patch - I'll just keep it in my own tree. The alternative is to trust someone with an extensive performance engineering background on Java platforms, and happily fly with it.





Archive powered by MHonArc 2.6.24.

Top of Page