Re: JDOM and memory

Rolf,

Sorry for rambling. Your original question about memory was related to 
getContent() and efficient iterators and I wanted to point out that 
getChildren() and related methods are more important to me.  I threw in 
a few other related methods and you've answered all my questions and 
taken actions beyond what I expected in such a short time frame.

I'm still doing a test migration to JDOM2, and so don't have any other 
comments at this time.

Leigh.


On 01/16/2012 04:20 PM, Rolf Lear wrote:
>
> Hi Leigh
>
> I am uncertain if I am missing something in whether your
> comments/suggestions are specifically related to memory improvement of
> JDOM2 (the subject line), or just general improvements. Reading your
> comments they seem to be unrelated to memory specifically, but more
> general performance/convenience. That's fine if it is, I just want to
> make sure I am not missing something...
>
> Just to summarize your mail very briefly, you are addressing three
> areas: getChild*(), XPath, and Exceptions
>
>
> getChild...()
> =============
>
> As for the getChild(...), getChildren(...) and getContent(Filter)
> methods. They all derive from the same concept ... create a FilterList
> on the underlying ContentList, and scan it for all available (or the
> first available for getChild(...) ) matching content.
>
> JDOM2 already has overridden the 'inefficient' iterator (and
> listIterator) methods to provide a more efficient iterator (a
> significant improvement in performance over JDOM 1.x see
> http://hunterhacker.github.com/jdom/jdom2/performance.html and scroll
> down about half the page to 'First major performance cycle', compare the
> results table to the one below.... )
>
> These improvements do *not* override the isEmpty() call though, and that
> should absolutely be overridden too. By default it compares size() == 0,
> and that would require a full scan of the underlying content, but
> iterator.hasNext() in JDOM2 only does a 'lazy' scan.
>
> So, introduce issue #57, override isEmpty() on FilterList. Since
> ContentList has a fast size() method then there is no need to change
> ContentList.isEmpty(). I am trying to think of any other methods that
> would be slow? There is no way to avoid a full scan for FilterList.size()
>
> So, in summary on the getChildren code... you should already be seeing
> improved performance on the getChildren() method calls with more
> efficient iterators, and soon the isEmpty will be even faster too.
>
> If/when the ContentList 'moves' in to Element to save memory, these
> improvements will be preserved.
>
>
> XPath
> =====
>
> In regards to the XPath I took notes from the XOM project which has the
> 'query()' method on all nodes... so for example you can:
>
> element.query(myxpath);
>
> I had a hard look at it and it makes some sense to do something similar.
> Especially now in JDOM2 where XPath supports more than just Element and
> Document 'context' items.
>
> The issue is that full XPath support requires both Namespace and
> 'Variable' contexts (XOM does address the Namespace context). This would
> be hard to implement on a simple 'query' method. Additionally, XPaths
> are intended to be 'compiled' and 'reused'. The XOM 'query'
> implementation does not support the reuse of the XPath. The simple query
> method would have to be limited, but would still cover (sucks out of
> thin air) 95% of XPath use in JDOM I am sure.
>
> So, the current XPath implementation in JDOM2 is able to do the full
> gamut of operation, but loses some convenience because you need to
> access it outside of the Element/Content.
>
> I certainly feel that making XPath more accessible to JDOM content would
> be 'friendly', but I worry that it will breed performance problems if it
> is too easy... At the time I worked the JDOM2 XPath code I looked in to
> what it would take to extend the functionality in to the 'Content' area
> of JDOM (like XOM), but found there were more issues than can be
> resolved by a person working alone with limited XPath experience (me). I
> figured I would come back to it. Perhaps now is the time.
>
> Still, taking your JDOMUtil examples:
>
> > JDOMUtil.selectElementChildren(element, xpath)
> > JDOMUtil.selectElement(element, xpath)
> > JDOMUtil.selectAttribute(element, xpath)
> > JDOMUtil.ref(Element element, String xpath, String defaultValue)
>
> In JDOM2, these same concepts can be 'easily' obtained with:
>
> Filters.element().filter(XPath.selectNodes(element, xpath));
> ... not sure what the selectElement() would do, but you get the idea.
> Filters.attribute().filter(XPath.selectNodes(element, xpath));
> ... well, the 'defaultValue' would take a tweak....
>
>
> Exceptions
> ==========
>
> Interesting observation. I can see the benefit of a JDOM 'Runtime'
> exception in addition to JDOMException. There are a few places where it
> could be useful to indicate a programmatic issue that does not need to
> be explicitly thrown/caught. XPath library is a good example.
>
> I'll think some more on that... see if I can see a problem with
> introducing JDOMRuntimeException...... and see what other places it
> would possibly make sense.
>
>
> So, thanks for the comments. If there's anything I missed,
> misunderstood, or needs attention, please don't hesitate!
>
> Rolf
>
> On 16/01/2012 4:36 PM, Leigh L Klotz Jr wrote:
> > 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.
> >
>

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