Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Severe performance regression (to 1.x) in certain cases #112
I'm a contributor to Ardor3D where jdom is used for handling a certain format of 3D models (Collada).
Recently I upgraded it from jdom 1.x to 2.x and today another contributor (@ricardolpd) noticed a big perfomance impact when loading one of his 4meg (xml) models. The slowdown happens when calling
I profiled everything using VisualVM and found the problem in
In jdom2, 60% of the time (which was the top hotspot when profiling) was spent in
which was called in
In jdom2, the array is resized directly in the
Can you spot the difference? In jdom2, the array is resized to exactly the requested size. In jdom1, it is resized with an additional amount of extra space (
My suggestion is to revert to the resizing behavior of jdom1. Is something speaking against that?
Also, the class javadoc of TextBuffer isn't current anymore. It is still related to the jdom1 version where a prefixString was used.
works, but uses deprecated XPath class
Hi, I have committed a fix to a new branch jdom-2.0.x which will be for the fixes coming to JDOM 2.0.5 and later. The master branch has items that are for JDOM 2.1.x and later (not yet released).
I am reluctant to create a full 2.0.5 build for this fix. It affects any users who have text content > 1024 chars, so it's a possibe 'big deal', but also the results are not 'wrong', just slow..... Typically, for JDOM, I schedule a release for 2-weeks after a fix is made, so that if anything eles comes up, it can be included too. I can provide a 'hotfix' as a short-term fix, or you can wait a couple of weeks, is there a preference?
One more question though. The javadoc says "A non-public utility class similar to StringBuilder but optimized for XML parsing where the common case is that you get only one chunk of characters per text section." This optimization isn't existing anymore in jdom2. Why? In its current version, TextBuffer is essentially a StringBuilder, with a different growing strategy.
Hi. I have identified why I am confused about the TextBuffer. In a previous life (before I became the JDOM Maintainer) I did a 'rework' ( http://markmail.org/message/e2ljuk56mz337fqj ) of the code and I removed the TextBuffer class. In this life I was more conservative, it seems, and tried to improve it instead (and introduced this performance 'feature'). I think I will be conservative again on the 2.0.x branch, but will replace it entirely on the master (2.1.x branch).