[jdom-interest] In the 11th Hour

Rolf Lear jdom at tuis.net
Thu Mar 22 08:31:39 PDT 2012


Hi all.

I am running out of things to do with JDOM, and that means that it's 
ready to release. I have been playing with the performance of critical 
parts of the code, and have recently committed some improvements. Still, 
the fact is that JDOM 2.x is ready to go unless something comes up....

... so, does anyone have any concerns?

I would really appreciate it if someone could go through the JavaDoc, 
check for any issues, etc. I have been through it a couple of times, and 
each time there's something to fix, and it is a thankless process. But a 
different set of eyes would be very useful.

I have one small performance issue to tackle, but, other than that 
there's nothing ... left ... to .... do ....

I anticipate making one more BETA version, probably Sunday Evening with 
the performance updates, but that will be the last one before the Easter 
release.

Here's the details on the performance of JDOM 2.x...

Rolf

 >> ========================

I have just pushed through some performance fixes. In essence the fixes 
restore all performance benchmarks (except one) to be better than the 
same benchmarks on JDOM 1.x.

http://hunterhacker.github.com/jdom/jdom2/performance.html

All benchmarks compare apples to apples, are all run on my laptop, with 
the same data, etc.

SAX Parsing is as fast as before (slightly faster - less than 5% - 
parsing times are too erratic to get meaningful times), but note, the 
benchmark only tests a single parse, and JDOM 2.x has massive 
improvements in parser reuse, so in general, JDOM 2.x is significantly 
better.

XMLOutputting is much faster than before, and additionally the API is 
more consistent. Output is at least 15% faster (8ms instead of 10ms)

XPath access is significantly faster (about a third faster 15ms instead 
of 24ms)

Creating JDOM content (cloning an entire tree) is slightly faster (7.5%) 
than before (7.4ms instead of 8ms).

Additionally, the memory footprint is 10% less than before (2.06MB 
instead of 2.26MB)

The only current performance 'slip' is the time it takes to scan an 
entire document and report the Elements in it. This has slipped 
significantly from 2.3ms to 3.1ms. I have been investigating it, and it 
appears to be a function of the additional functionality in the 
DescendantIterator, and the type-safety of the code. I am still working 
on it though.


More information about the jdom-interest mailing list