Re: JDOM and memory

I'm currently evaluating the alpha of JDOM2.  Most of the problems I've 
found with JDOM and Java 6 have been fixed in a utility class I have 
called JDOMUtil.  A good deal of the methods in there are handling 
generic types,

As for the question below, I don't often have the use case of for() 
iterating over, element.getContent(), but I do often iterate over the 
following:
   element.getChildren()
   element.getChildren(name)
   element.getChildren().isEmpty() as a surrogate for element.hasChildren()

You could have Element.getContent() return a List implementation of your 
own, and make the Iterable.iterate() method in it (which is what for() 
calls) be efficient.  That might also make element.getChildren.hasNext 
be efficient, or you could implement isEmpty directly.

For JDOMUtil, I often use these:
    JDOMUtil.selectElementChildren(element, xpath)
    JDOMUtil.selectElement(element, xpath)
    JDOMUtil.selectAttribute(element, xpath)
    JDOMUtil.ref(Element element, String xpath, String defaultValue)

The JDOMUtil.ref(Element element, String xpath, String defaultValue) 
method returns either the leaf-node value of the XPath expression, or 
the defaultValue if the nodeset is empty.

I've also wrapped every one of the JDOMUtil XPath calls with something 
that throws a RuntimeException wrapper for JDOMException, and I let pass 
JDOMException and IOException only on serialization and parsing 
utilities.  I believe that checked exceptions for XPath errors are a 
detraction from the simplicity of JDOM.  XPath exceptions are always 
internal programming errors, and it is the rare case where they can be 
corrected at the point of invocation. Parsing and IO exceptions can come 
from external system interaction and can reasonably be expected to be 
correctable in point source code.

Leigh.

On 01/02/2012 12:27 PM, Rolf wrote:
>
> Hi all.
>
> Memory optimization has never been a top priority for JDOM. At the same
> time, for what it does, JDOM is not a 'terrible' memory user. Still, I
> have done some analysis, and, I believe I can trim about a quarter to a
> half of 'JDOM Overhead' memory usage by making two 'simple' changes....
>
> The first is to merge the ContentList class in to the Element class (and
> also in to Document). This will reduce the number of Java objects by
> about half, and that will save about 32 bytes per Element at a minimum
> in a 64-bit JRE. Additionally, by lazy-initialization of the Content
> array, we can save memory on otherwise 'empty' Elements.
>
> This can be done by extending the Element (and perhaps Document) class
> to extend 'List'. It can all be done in a 'backward compatible' way, but
> also leads to some interesting possibilities, like:
>
>    for (Content c : element) {
>       ... do something
>    }
>
> (for backward compatibility, Element.getContent() will return 'this').
>
>
> The second change is to make the AttributeList instance in Element a
> lazy-initialization. This would save memory on all Elements that have no
> attributes, but would have an impact for people who sub-class the
> Element class and may expect the attributes field to be non-null.
>
>
> I am trying to get a feel for how important this sort of optimization
> may be. If there is interest then I will make some changes, and test the
> impact. I may make a separate branch in github to test it out....
>
> If the above changes are unrealistic then I don't think it makes sense
> to even try....
>
> Rolf
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/[email protected]
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]