Baz wrote:
> On 07/03/07, Nikhil Dinesh <nikhild@seas.upenn...> wrote:
>> Yep, you're right. Would you expect such a big difference in times
>> though? It's just one additional level of iteration,, if
>> descendant-or-self::X is run against the document.  Even a nested loop
>> of descendant iterators is faster than //X. I can test this more
>> systematically, if this is unexpected.
>>
>
> Yes, it would be expected to make a difference. The way jaxen works
> internally, it fills in the entire list for each step before moving on
> to the next step. Also, navigators can accellerate certain operations
> (in this case, looking for elements with a particular name). So what
> you've tested there is collecting all the nodes in the entire doc, and
> performing a second step on each of them, vs collecting some of the
> elements (no attributes, PIs, text, etc) via a faster path.

I didn't know that attributes and namespace nodes were selected by
/descendant-or-self::node(). My reading of the spec is not careful enough,
I thought they meant something closer to the way DOM uses these things.
Here is an excerpt from 5.2:

"""
The children of an element node are the element nodes, comment nodes,
processing instruction nodes and text nodes for its content. Entity
references
to both internal and external entities are expanded. Character
references are resolved.
"""

and from 5.3:

"""
Each element node has an associated set of attribute nodes; the element
is the parent <http://www.w3.org/TR/xpath#dt-parent> of each of these
attribute nodes; however, an attribute node is not a child of its parent
element.
"""

Perhaps I'm misinterpreting what you said. Also, the navigator I use is
one that I wrote which has no
optimizations for looking up an element by name. I perform a dumb
iteration over the entire tree comparing
names (but only over non-attribute and namespace nodes). I only have
elements and attributes and nothing
else.
>
> While jaxen should really be collecting its internal lists lazily, the
> main source of its slowness, it wouldn't have helped much in this
> case. I suspect theres some generic optimisations we could do here,
> but as a special case descendant-or-self::node()/child::expr is always
> the same as descendant::expr, and its a common enough case that it
> might be worth fixing. Other obvious similar identities:
>
> descendant-or-self::node()/descendant::<test> -> descendant::<test>
> ancestor-or-self::node()/parent::<test> -> ancestor::<test>
> ancestor-or-self::node()/ancestor::<test> -> ancestor::<test>
> self::node()/<step> -> <step>
> ... but none of these, except maybe the last one, come up in common
> usage. The spec even includes this example:
>
> "A location step of . is short for self::node(). This is particularly
> useful in conjunction with //. For example, the location path .//para
> is short for
>
> self::node()/descendant-or-self::node()/child::para
>
> and so will select all para descendant elements of the context node."
>
> Hmm, so we should optimise that to descendant::para then?
I'd definitely be in favour of these optimizations, but I'm not sure if
the useful cases can be
handled in a spec compliant manner, since they note that:

//para[1] is not the same as |/descendant::para[1]|.

Which means that there probably is no clean way to optimize when a
predicate is involved, since
Jaxen allows user defined functions.

Sigh. Someone should lean on the spec writers to produce good
abbreviated syntax for all axes.

Thanks,
-Nikhil

>
> Cheers,
> Baz
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>