[jdom-interest] About JDOM performance

phil at triloggroup.com phil at triloggroup.com
Tue May 22 02:19:56 PDT 2001


Hi,

As I'm using JDOM, I did many performance checks with the Beta6/7 release.

First,  it seems that 2 methods create unwanted PartialList : Element.getMixedContent() & Element.getAttributes(). Since
the partial lists in these cases are an exact copy of the contained lists, it is safer to return these lists instead of
creating a temporary partial list. As we are parsing a tree by calling several times these methods, JProbe pointed out a
gain of more than 50% by using modified methods!! I think this is an error, since the Document.getMixedContent() is
correctly implemented.

Secundo, getChildren()/getAttributes() are also a performance bottleneck. I think that methods like getChildrenIterator
()/getAttributesIterator(), using a filtering iterator, will prevent the partial list creation and greatly enhance
performance. I saw that many times we are doing code like Iterator it=element.getChildren().iterator(). If you need such
filtering iterator implementation, I can send a simple one to you.

Tierco, the LinkedList use is really memory consumming. For example, I'm parsing HTML files and JProbe stated that more
than 11,000 LinkedList$Entry objects were created! Moreover, debugging (with JBuilder) these list content is really
cumbersome since you cannot directly view an absolute item.
According to many books on Java perfomance, linked lists are definitively slower than an array based collection, except
for some kind of Queue, which is not
how JDOM use the collections. Please, let us using the List implementation we want...

Finally, the systematic checking of parameters is really annoying: to overcome them, I created my own classes derivated
from the original one (Element...) and it created a tree more than 2 times faster. I think that such checking must be
optional. It is a really good option but may be disabled: when I read my DOM from a database, I sure that it is already
valid...
But the question is how to know if it has to be checked or not. A static option is not thread safe, a parameter in the
underlying document is not always available (for example, an Element constructor does not know about the Document).
Well, after thinking about this, I founded that the more reliable solution is to add a 'boolean validate' to each ctor
and methods that do a validation (addAttribute()...). We will then have something like:
Element( String name, boolean validate) {
    if( validate ) {...} // Do validation
}
Element( String name) {
    this(name,true); // Validation is done by default.
}

Please, give me your feedback about that. Today, JDOM is a great framework but really needs some optimizations to be use
in a production context.

Phil.




More information about the jdom-interest mailing list