[jdom-interest] In the 11th Hour
jdom at tuis.net
Thu Mar 22 08:31:39 PDT 2012
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
Here's the details on the performance of JDOM 2.x...
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.
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
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
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