In the 11th Hour
Rolf Lear <[email protected]> Thu, 22 Mar 2012 11:31:39 -0400
| Newsgroups | gmane.comp.java.jdom.general |
|---|---|
| Message-ID | <[email protected]> |
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. _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/[email protected]