XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> 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.